Handling of c++ function members
Joost van der Sluis
joost@cnoc.nl
Sun Oct 2 13:51:00 GMT 2011
On Fri, 2011-09-30 at 10:42 -0400, Daniel Jacobowitz wrote:
> On Tue, Sep 27, 2011 at 10:59 AM, Joost van der Sluis <joost@cnoc.nl> wrote:
> >> What I understood is, that DW_AT_vtable_elem_location should contain a
> >> Dwarf-block that calculates the location of a pointer in which the
> >> location of the function member is stored.
>
> Your final conclusion is right - I thought the workaround was
> contained to the dwarf reader, but maybe not.
Indeed. The workaround in the dwarf-reader is when it encounters a
Dwarf-block for a DW_AT_vtable_elem_location entry, it assumes that the
dwarf-block contains a simple DW_OP_deref, a constant and DW_OP_plus.
Then it takes the constant, divides it by the pointer-size and then it
has the index-element, just like it had when using stabs or with older c
++ compilers.
So the actual Dwarf-block is not evaluated at all. But hey, it works
now, even with FPC.
> Are you actually passing through gnu-v2-abi.c? Everythong ought to be
> on the v3 abi unless this is another FPC quirk...
It's (as almost always) the other way around and a gcc quirk. The
default is gnu-v2. But when a symbol's name start with '_Z' then it is
set to gnu-v3.
Really, gdb contains a pile of hacks to get it working with gcc. That's
not a problem but sometimes difficult when other compilers try to work
with the official Dwarf-specifications.
Regards,
Joost van der Sluis.
More information about the Gdb
mailing list