[fpc-devel] Dwarf3 and the encoding of classes

[Martin]

On 09/01/2011 19:51, Joost van der Sluis wrote:
> On Sun, 2011-01-09 at 17:50 +0000, Martin wrote:
>> On 09/01/2011 16:56, Joost van der Sluis wrote:
>>>>> This has nothing to do with gdb, but with the debug-information that
>>>>> fpc
>>>>> (-gw3) generates. Now it handles classes as if they are not
>>>>> pointers. I
>>>>> think that this is closer to how a class is defined in Pascal. A class
>>>>> is (imho) not a pointer, just like an ansistring is not a pointer.
>>>>>
>> ...
>>> I've done some more tests with -gw2. 'p classinstance' gives you the
>>> address of the class-instance and not the values within the class.
>>> That's a big issue to me. To show the class, you have to use 'p
>>> classinstance^', which is nonsense in a Pascal-way of view.
>>>
>>> And if the classinstance is nil it shows '0x0' and not 'nil'. 'p
>>> @classinstance' will give you rubbish.
>>>
>>> Otoh, with gw3, this all works. The patch to show 'nil' when a class is
>>> not assigned for gdb is two lines. And to be honest, I think the 'p
>>> classinstance1=classinstance2' case is a real corner-case. The cases
>>> explained above are more important, imho. w2) you can)
>> ...
>>> Overall, I think that omitting the implicit-pointer as Dwarf-3 does now,
>>> is the right way to go, so I'll continue with that.
>> Another point....
>> The above is all true, if debugging directly in gdb...
>>
>> ---
>> In terms of consistency, stabs and dwarf both currently handle classes
>> as pointers. Yet they display type info differently.
> It might be that it is all consistent, but that way we are building a
> complete new universe, which is consistent with itself, but inconsistent
> with both the official Dwarf standard and the Pascal language. I want to
> clear up all the debug-mess. All hacks and workarounds, which are
> applied just to make it work.
Sure.

I didn't mean that an argument against fixing things. Like "we cant fix 
it, because we rely on it being broken"

> But yes, we need something so that Lazarus can keep both systems apart.
> (To make that difficult, units with other debug-formats can be used
> together...)
Yeah, I had that feeling, and I will have to add that to tests too.

BTW: did you see my other mails?
If you are fixing gdb too, can gdb please output "ptype set" more 
menaingfull?

ptype enum, gives a list of all the enum values.
ptype set (dwarf) gices: set of low..high
no way to get the other values.

The values are there, they are in the dwarf info, but gdb does not print 
them....


>> ----
>> What about something like what happens with pchar?
>> where gdb shows the address, followed by the data?
>>
>> No idea, if possible....
> Yes, offcourse. Not that difficult, but needs a gdb patch. But then
> there's still the @ and the nil issues. But I have to investigate Jonas
> mail about that first.
Well it sounded like gdb may need a patch (or two) anyway?

And I guess "pchar1 = pchar2 does evaluate?


>> ----
>> So for the IDE it is already quite a trick (but entirely possible) to
>> find out what it is looking at.
>>
>> If you change the way, the data is represented in future, then my
>> question is:
>> Is there any whatis or ptype command, that will have a different output?
>> So the IDE can still detect what is happening.
> You don't need the whatis and ptype commands anymore, because everything
> will be showed directly. This was all necessary (for classes) to work
> around the gdb/fpc debugging-issues. I want to solve those underlying
> issues.
there is another diff between ptype and whatis

ptype shows the final type.
ptype shows ONE ^, never mind how many levels of pointers

whatis shows the next type

type
   TFoo = Class ... end;
   PFoo = ^TFoo;
   PPFoo = ^PFoo;
var
   Foo: PPFoo;

ptype Foo
    type = ^TFoo = class
// just assume the ^ is for the pointer, not the class => it would be if 
TFoo had been "Tfoo = Int64" instead...

whatis Foo
   type = PPFoo
whatis PPFoo
   type = PFoo

of course hard to say if PPFoo  was just another name for PFoo
   type PPFoo = TYPE PFoo
(depending on symbol type, that may give 2 types in gdb)

I haven tried
   whatis Foo^
but that should be a save way to detect things...

--------------
The other issue is, that issuing a command (at least on w32) is a slow 
thing to do.

The more ptype and whatis are needed, the worse it gets....



>> [1] casting is needed under dwarf for param by ref types (var param /
>> constref) =>they are encoded with that "&", they work fine, if in an
>> expression, but not if standalone. Typecasting them, to the type they
>> already are, makes them work.....
> That was another work-around. Which isn't necessary anymore with current
> fpc-trunk. (You can try your lazarus-debug-tests, remove the nodwarf
> flags from the var-tests)

I will, as soon as my IDE works again => in the middle of reworking the 
gdb type parser....


>> =>  one thing would be: for "Bar: TFoo;" (where TFoo is a class)
>> ptype Bar
>> ~"type = TFoo = class : public TOBJECT \n"
>>
>> because at current, both stabs and dwarf return: (note the "^" before TFoo)
>> ~"type = ^TFoo = class : public TOBJECT \n"
>>
>> while for using ptype on the class, not the variable
>> ptype TFoo
>> dwarf has the ^  and stabs does not.....
> I don't understand this entirely, but we have to find a solution for
> this.

currently both dwarf and stabsd add the ^ before classes.

Both have differnet ways to find out, if it is a real (pointer~) ^ => or 
a dummy, "I am a class" ^.

if I do
   ptype SomeVariableObject
there will always be a ^ in front of the name

If I do
   ptype TObject
   ptype PObject

then stabs will give the ^ only for PObject => good
but dwarf will have it both times

under dwarf I can do:
   whatis TObject
   whatis PObject
and it gives
   type = ^TObject = class    // not a pointer
   type = ^TObject =            // this is a pointer

Isn't live just fun???

----
So if we add new formats

I could detect

ptype Foo
   type = TFoo = claa: public ...
I would see and detect the missing ^ => and I would know it is the new 
finally good dwarf3 encoding.

BUT
ptype FooPointer
   type = ^TFoo = claa: public ...

because FooPointer is "PFoo = ^TFoo", the gdb result would (correctly) 
have the ^
Only now i need a way to know, this ^ does mean, what it should.

Because it looks no different from the current dummy ones................

Martin