This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Handling of c++ function members
- From: Joost van der Sluis <joost at cnoc dot nl>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sourceware dot org
- Date: Sun, 02 Oct 2011 15:50:47 +0200
- Subject: Re: Handling of c++ function members
- References: <1317055596.23338.12.camel@feddie.cnoc.lan> <CAN9gPaE0K+z-8H5NyHmHg2KcYz2QEAHOy=eXC28bva0-zD4xhg@mail.gmail.com> <1317070857.17681.11.camel@feddie.cnoc.lan> <1317135598.27942.29.camel@feddie.cnoc.lan> <CAN9gPaHjTjxDZ+zhMZ3zR0-jb_Xaeh7VH1EQHRewUaELnPfQGw@mail.gmail.com>
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.