* Handling of c++ function members
@ 2011-09-26 16:46 Joost van der Sluis
2011-09-26 20:38 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Joost van der Sluis @ 2011-09-26 16:46 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-09-26 16:46 Handling of c++ function members Joost van der Sluis
@ 2011-09-26 20:38 ` Daniel Jacobowitz
2011-09-26 21:01 ` Joost van der Sluis
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2011-09-26 20:38 UTC (permalink / raw)
To: Joost van der Sluis; +Cc: gdb
On Mon, Sep 26, 2011 at 12:46 PM, Joost van der Sluis <joost@cnoc.nl> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-09-26 20:38 ` Daniel Jacobowitz
@ 2011-09-26 21:01 ` Joost van der Sluis
2011-09-27 15:05 ` Joost van der Sluis
0 siblings, 1 reply; 11+ messages in thread
From: Joost van der Sluis @ 2011-09-26 21:01 UTC (permalink / raw)
To: gdb
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 <joost@cnoc.nl> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-09-26 21:01 ` Joost van der Sluis
@ 2011-09-27 15:05 ` Joost van der Sluis
2011-09-27 16:01 ` Joost van der Sluis
2011-09-30 14:42 ` Daniel Jacobowitz
0 siblings, 2 replies; 11+ messages in thread
From: Joost van der Sluis @ 2011-09-27 15:05 UTC (permalink / raw)
To: gdb
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 <joost@cnoc.nl> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Handling of c++ function members
2011-09-27 15:05 ` Joost van der Sluis
@ 2011-09-27 16:01 ` Joost van der Sluis
2011-09-30 14:42 ` Daniel Jacobowitz
1 sibling, 0 replies; 11+ messages in thread
From: Joost van der Sluis @ 2011-09-27 16:01 UTC (permalink / raw)
To: gdb
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 <joost@cnoc.nl> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-09-27 15:05 ` Joost van der Sluis
2011-09-27 16:01 ` Joost van der Sluis
@ 2011-09-30 14:42 ` Daniel Jacobowitz
2011-09-30 15:53 ` Joost van der Sluis
2011-10-02 13:51 ` Joost van der Sluis
1 sibling, 2 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2011-09-30 14:42 UTC (permalink / raw)
To: Joost van der Sluis; +Cc: gdb
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.
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-09-30 14:42 ` Daniel Jacobowitz
@ 2011-09-30 15:53 ` Joost van der Sluis
2011-09-30 18:50 ` Jan Kratochvil
2011-10-02 13:51 ` Joost van der Sluis
1 sibling, 1 reply; 11+ messages in thread
From: Joost van der Sluis @ 2011-09-30 15:53 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
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.
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-09-30 15:53 ` Joost van der Sluis
@ 2011-09-30 18:50 ` Jan Kratochvil
2011-09-30 20:37 ` Joost van der Sluis
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kratochvil @ 2011-09-30 18:50 UTC (permalink / raw)
To: Joost van der Sluis; +Cc: Daniel Jacobowitz, gdb
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-09-30 18:50 ` Jan Kratochvil
@ 2011-09-30 20:37 ` Joost van der Sluis
0 siblings, 0 replies; 11+ messages in thread
From: Joost van der Sluis @ 2011-09-30 20:37 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: Daniel Jacobowitz, gdb
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-09-30 14:42 ` Daniel Jacobowitz
2011-09-30 15:53 ` Joost van der Sluis
@ 2011-10-02 13:51 ` Joost van der Sluis
2011-10-05 18:56 ` Tom Tromey
1 sibling, 1 reply; 11+ messages in thread
From: Joost van der Sluis @ 2011-10-02 13:51 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Handling of c++ function members
2011-10-02 13:51 ` Joost van der Sluis
@ 2011-10-05 18:56 ` Tom Tromey
0 siblings, 0 replies; 11+ messages in thread
From: Tom Tromey @ 2011-10-05 18:56 UTC (permalink / raw)
To: Joost van der Sluis; +Cc: Daniel Jacobowitz, gdb
>>>>> "Joost" == Joost van der Sluis <joost@cnoc.nl> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-10-05 18:56 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-26 16:46 Handling of c++ function members Joost van der Sluis
2011-09-26 20:38 ` Daniel Jacobowitz
2011-09-26 21:01 ` Joost van der Sluis
2011-09-27 15:05 ` Joost van der Sluis
2011-09-27 16:01 ` Joost van der Sluis
2011-09-30 14:42 ` Daniel Jacobowitz
2011-09-30 15:53 ` Joost van der Sluis
2011-09-30 18:50 ` Jan Kratochvil
2011-09-30 20:37 ` Joost van der Sluis
2011-10-02 13:51 ` Joost van der Sluis
2011-10-05 18:56 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).