[fpc-devel] Dwarf3 and the encoding of classes

[Martin]

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.

And currently, with both stabs and dwarf (-gw) can do:
   Foo.Value
withou having to write the "^".

the ^ is only needed if Foo is standalone

----
What about something like what happens with pchar?
where gdb shows the address, followed by the data?

No idea, if possible....

----
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.

Yes of course, it can look at the data returned. But that makes it even 
trickier. Because at current the data is only retrieved with the help of 
the type info, so all the workarounds for dereferencing, or casting [1] 
can be applied

[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.....


=> 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.....