[fpc-devel] Dwarf3 and the encoding of classes

[Joost van der Sluis]

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. 

The basic example: in the GDB sources there is a comment that all
identifiers are uppercased, because the fpc compiler does that too. And
in the fpc-compiler there was the comment that the identifiers had to be
uppercased because GDB needs that. I want to get rid off that. 

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

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

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

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

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

Joost.