Handling of c++ function members

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Handling of c++ function members

Joost van der Sluis
Hi all,

I've been looking at the code which handles calling c++ function members
and the Dwarf specifications. Is came to the conclusion that gcc does
not generate valid Dwarf-debuginfo for those function members, but a
work-around which is also implemented in gdb, namely in gnu-v2-abi.c.

Is my conclusion right?

Regards,
 
Joost van der Sluis.



Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Daniel Jacobowitz-2
On Mon, Sep 26, 2011 at 12:46 PM, Joost van der Sluis <[hidden email]> wrote:
> Hi all,
>
> I've been looking at the code which handles calling c++ function members
> and the Dwarf specifications. Is came to the conclusion that gcc does
> not generate valid Dwarf-debuginfo for those function members, but a
> work-around which is also implemented in gdb, namely in gnu-v2-abi.c.
>
> Is my conclusion right?

Can you be a little more specific, maybe an example?

There are definitely oddities in the GCC debug info, but the
workarounds I remember are in the DWARF reader.

--
Thanks,
Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Joost van der Sluis
On Mon, 2011-09-26 at 16:38 -0400, Daniel Jacobowitz wrote:

> On Mon, Sep 26, 2011 at 12:46 PM, Joost van der Sluis <[hidden email]> wrote:
> > Hi all,
> >
> > I've been looking at the code which handles calling c++ function members
> > and the Dwarf specifications. Is came to the conclusion that gcc does
> > not generate valid Dwarf-debuginfo for those function members, but a
> > work-around which is also implemented in gdb, namely in gnu-v2-abi.c.
> >
> > Is my conclusion right?
>
> Can you be a little more specific, maybe an example?
>
> There are definitely oddities in the GCC debug info, but the
> workarounds I remember are in the DWARF reader.

Problem is that I'm not sure is I read the Dwarf-spec's regarding
function members correctly.

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.

But it seems to me that gcc stores the index of the function member
within some vtable in DW_AT_vtable_elem_location, instead of the memory
address itself. In gnu-v2-abi.c there is some code that 'knows' how this
vtable is organized so it is able to calculate the location of the
method-pointer.

And there are two thing's I'm not sure about: gcc stores
DW_AT_containing_type in the debug-info, with the 'parent' entry of the
DW_TAG_subprogram entry. To me it looks that this is duplicated
information, and not specified in the Dwarf-specs. Secondly I do not
understand where the DW_AT_object_pointer is used for?

Joost.

Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Joost van der Sluis
On Mon, 2011-09-26 at 23:00 +0200, Joost van der Sluis wrote:
> On Mon, 2011-09-26 at 16:38 -0400, Daniel Jacobowitz wrote:
> > On Mon, Sep 26, 2011 at 12:46 PM, Joost van der Sluis <[hidden email]> wrote:
> >
> > Can you be a little more specific, maybe an example?
> >

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

If you need an example, you can compile the wikipedia
virtual-function-example (after fixing compilation by adding the
declaration of 'it') http://en.wikipedia.org/wiki/Virtual_function

objdump -W of the function 'eat' in that example:
 <1><1902>: Abbrev Number: 66 (DW_TAG_class_type)
    <1903>   DW_AT_name        : (indirect string, offset: 0x17e6): Animal      
    <1907>   DW_AT_byte_size   : 8      
    <1908>   DW_AT_decl_file   : 2      
    <1909>   DW_AT_decl_line   : 4      
    <190a>   DW_AT_containing_type: <0x1902>    
    <190e>   DW_AT_sibling     : <0x19be>
 <2><1953>: Abbrev Number: 69 (DW_TAG_subprogram)
    <1954>   DW_AT_external    : 1      
    <1955>   DW_AT_name        : eat    
    <1959>   DW_AT_decl_file   : 2      
    <195a>   DW_AT_decl_line   : 6      
    <195b>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0xad3): _ZNK6Animal3eatEv      
    <195f>   DW_AT_virtuality  : 1      (virtual)
    <1960>   DW_AT_vtable_elem_location: 2 byte block: 10 0     (DW_OP_constu: 0)
    <1963>   DW_AT_containing_type: <0x1902>    
    <1967>   DW_AT_accessibility: 1     (public)
    <1968>   DW_AT_declaration : 1      
    <1969>   DW_AT_object_pointer: <0x1971>    
    <196d>   DW_AT_sibling     : <0x1978>      
 <3><1971>: Abbrev Number: 25 (DW_TAG_formal_parameter)
    <1972>   DW_AT_type        : <0x2a55>      
    <1976>   DW_AT_artificial  : 1

> But it seems to me that gcc stores the index of the function member
> within some vtable in DW_AT_vtable_elem_location, instead of the memory
> address itself. In gnu-v2-abi.c there is some code that 'knows' how this
> vtable is organized so it is able to calculate the location of the
> method-pointer.
>
> And there are two thing's I'm not sure about: gcc stores
> DW_AT_containing_type in the debug-info, with the 'parent' entry of the
> DW_TAG_subprogram entry. To me it looks that this is duplicated
> information, and not specified in the Dwarf-specs. Secondly I do not
> understand where the DW_AT_object_pointer is used for?

DW_AT_containing_type is placed into NFN's Context field by dwarf2read.

Regards,

Joost van der Sluis.

Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Joost van der Sluis
On Tue, 2011-09-27 at 16:59 +0200, Joost van der Sluis wrote:

> On Mon, 2011-09-26 at 23:00 +0200, Joost van der Sluis wrote:
> > On Mon, 2011-09-26 at 16:38 -0400, Daniel Jacobowitz wrote:
> > > On Mon, Sep 26, 2011 at 12:46 PM, Joost van der Sluis <[hidden email]> wrote:
> > >
> > > Can you be a little more specific, maybe an example?
> > >
>
> > 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.

> > But it seems to me that gcc stores the index of the function member
> > within some vtable in DW_AT_vtable_elem_location, instead of the memory
> > address itself. In gnu-v2-abi.c there is some code that 'knows' how this
> > vtable is organized so it is able to calculate the location of the
> > method-pointer.

Never mind. I've found a comment in dwarf2read explaining that older gcc
versions are indeed using indexes, while 'everything else' doesn't. So I
wrote a patch for the Free Pascal Compiler so that it does what
'everything else' does...

Regards,

Joost van der Sluis.

Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Daniel Jacobowitz-2
In reply to this post by Joost van der Sluis
On Tue, Sep 27, 2011 at 10:59 AM, Joost van der Sluis <[hidden email]> 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.

Are you actually passing through gnu-v2-abi.c?  Everythong ought to be
on the v3 abi unless this is another FPC quirk...

>> And there are two thing's I'm not sure about: gcc stores
>> DW_AT_containing_type in the debug-info, with the 'parent' entry of the
>> DW_TAG_subprogram entry. To me it looks that this is duplicated
>> information, and not specified in the Dwarf-specs. Secondly I do not
>> understand where the DW_AT_object_pointer is used for?
>
> DW_AT_containing_type is placed into NFN's Context field by dwarf2read.

The use of DW_AT_containing_type by GCC is non-standard, yes.

DW_AT_object_pointer is supposed to be used to identify "this"
explicitly, I think, but it's been a while.  Without it, you can't
100% differentiate "int x()" from "static int x(X *this)" in the
debugger.  Fortunately we get it right in practice.

--
Thanks,
Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Joost van der Sluis
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 <[hidden email]> 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.

Yes, I've found it.

> Are you actually passing through gnu-v2-abi.c?  Everythong ought to be
> on the v3 abi unless this is another FPC quirk...

Well, I've used the virtual-function example for c++ from wikipedia,
compiled it  (gcc 4.6.1) on Fedora 15 and loaded it into gdb. Stepping
though gdb it indeed passed gnu-v2-abi.c. So fpc wasn't involved at all.

Regards,

Joost.

Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Jan Kratochvil-2
On Fri, 30 Sep 2011 17:53:06 +0200, Joost van der Sluis wrote:
> Well, I've used the virtual-function example for c++ from wikipedia,
> compiled it  (gcc 4.6.1) on Fedora 15 and loaded it into gdb. Stepping
> though gdb it indeed passed gnu-v2-abi.c. So fpc wasn't involved at all.

I do not understand why do you see it:
$ gdb -nx ./animals -ex 'show cp-abi'
The currently selected C++ ABI is "auto" (currently "gnu-v3").

(both FSF GDB and Fedora GDB)


Regards,
Jan
Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Joost van der Sluis
On Fri, 2011-09-30 at 20:50 +0200, Jan Kratochvil wrote:
> On Fri, 30 Sep 2011 17:53:06 +0200, Joost van der Sluis wrote:
> > Well, I've used the virtual-function example for c++ from wikipedia,
> > compiled it  (gcc 4.6.1) on Fedora 15 and loaded it into gdb. Stepping
> > though gdb it indeed passed gnu-v2-abi.c. So fpc wasn't involved at all.
>
> I do not understand why do you see it:
> $ gdb -nx ./animals -ex 'show cp-abi'
> The currently selected C++ ABI is "auto" (currently "gnu-v3").

Sorry, you're right. It was with the fpc-application.

Joost.

Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Joost van der Sluis
In reply to this post by Daniel Jacobowitz-2
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Handling of c++ function members

Tom Tromey
>>>>> "Joost" == Joost van der Sluis <[hidden email]> writes:

Joost> Really, gdb contains a pile of hacks to get it working with gcc. That's
Joost> not a problem but sometimes difficult when other compilers try to work
Joost> with the official Dwarf-specifications.

In recent years we've been trying to update GCC to conform better, and
also to update GDB.  We'd appreciate more help along these lines :-)
Or even just bug reports about what is still wrong.

Tom