[fpc-devel] Dwarf3 and the encoding of classes

Joost van der Sluis joost at cnoc.nl
Mon Jan 3 13:29:02 CET 2011

On Mon, 2011-01-03 at 19:12 +0700, Paul Ishenin wrote:
> 03.01.2011 18:30, Joost van der Sluis wrote:
> > There are a few issues, though:
> >   - If a class is not assigned (=nil), gdb shows the message that the
> > class is not assigned. It doesn't show that it is nil. (Effectively this
> > means the same offcourse, is this a problem? Should gdb be patched to
> > show nil?)
> Yes. Nil is a value which is assigned to a class instance and therefore 
> should be shown.
> > - You can not compare two classes in gdb. It will complain that there is
> > no operator to compare two classes. Which is right, offcourse. But in
> > Pascal normally the addresses of the classes are compared when you
> > compare two classes. Gdb can't handle that.
> Maybe to declare an operator? Looks like gdb understands FPC class as 
> C++ class which is not a pointer?

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. After
all, we don't use AnObject^.Destroy.... 

So we have to choose what to do: make the implicit pointer visible in
the debug-info and add some hacks to gdb that it converts
AnObject.Destroy to AnObject^.Destroy. (This is what we do with stabs
and Dwarf < 3)

Or we 'hide' the implicit pointer so that AnObject.Destroy works, but we
have to add some hacks to gdb so that an unallocated class is shown as
'nil', and add the ability to do pointer-arithmetic on classes. (Like
comparing two classes)

Two options, both have there pro's and con's?


More information about the fpc-devel mailing list