public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* c++/7081: DWARF enhancements for C++
@ 2002-06-20 3:06 jcownie
0 siblings, 0 replies; 3+ messages in thread
From: jcownie @ 2002-06-20 3:06 UTC (permalink / raw)
To: gcc-gnats
>Number: 7081
>Category: c++
>Synopsis: DWARF enhancements for C++
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Thu Jun 20 02:16:04 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: James Cownie
>Release: 3.1
>Organization:
Etnus LLC
>Environment:
System: Linux pc4 2.4.18 #1 Tue Apr 2 10:17:01 BST 2002 i686 unknown
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /home1/GNU/gcc-3.1/configure
>Description:
1) g++ emits classes in DWARF with the DW_TAG_structure_type rather
than the DW_TAG_class_type which is suggested in the DWARF V3
specification. This makes it hard for a debugger to show the type
name correctly since it can't tell whether the class was _really_
introduced by the class or struct keywords.
2) g++ does not emit any debug information for the vtable pointer in
classes with virtual functions. It would be much nicer if this
information were emitted (tagged with AT_artificial), since it's
often very useful to be able to see the vtable pointer while
debugging, as that's how one can work out which class an object
_actually_ is when one is looking at a base class pointer.
>How-To-Repeat:
Using code like this
#define class_body(classname) \
{ \
char * classname##_data; \
public: \
classname () { classname##_data = #classname " data"; } \
virtual char * get_##classname##_data () { return classname##_data; } \
}
class A class_body (A);
class B class_body (B);
class foo: virtual public A, public B class_body (foo);
int main (int argc, char **argv)
{
foo f00;
int i = 1;
}
Compile it and use readelf to look at the dwarf. One can then observe
1) <1><cb>: Abbrev Number: 7 (DW_TAG_structure_type)
DW_AT_sibling : <1b3>
DW_AT_name : foo
DW_AT_byte_size : 20
DW_AT_decl_file : 1
DW_AT_decl_line : 12
DW_AT_containing_type: <2e1>
So "foo" is a "struct", not a "class".
2) Eliding the member functions, the contents of class foo are
<1><cb>: Abbrev Number: 7 (DW_TAG_structure_type)
DW_AT_sibling : <1b3>
DW_AT_name : foo
DW_AT_byte_size : 20
DW_AT_decl_file : 1
DW_AT_decl_line : 12
DW_AT_containing_type: <2e1>
<2><db>: Abbrev Number: 8 (DW_TAG_inheritance)
DW_AT_type : <227>
DW_AT_data_member_location: 6 byte block: 12 6 3c 1c 6 22 (DW_OP_dup; DW_OP_deref; DW_OP_lit12; DW_OP_minus; DW_OP_deref; DW_OP_plus; )
DW_AT_virtuality : 1 (virtual)
DW_AT_accessibility: 1 (public)
<2><e9>: Abbrev Number: 9 (DW_TAG_inheritance)
DW_AT_type : <2e1>
DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0; )
DW_AT_accessibility: 1 (public)
<2><f2>: Abbrev Number: 10 (DW_TAG_member)
DW_AT_name : foo_data
DW_AT_decl_file : 1
DW_AT_decl_line : 12
DW_AT_type : <bd>
DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8; )
DW_AT_accessibility: 3 (private)
So there is no information about the vtable pointer.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c++/7081: DWARF enhancements for C++
@ 2002-06-20 10:16 James Cownie
0 siblings, 0 replies; 3+ messages in thread
From: James Cownie @ 2002-06-20 10:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/7081; it has been noted by GNATS.
From: James Cownie <jcownie@etnus.com>
To: gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: c++/7081: DWARF enhancements for C++
Date: Thu, 20 Jun 2002 17:36:01 +0100
> This one isn't really necessary. The ABI specifies where the vtable
> pointer will be, and GDB is quite capable of using that knowledge to
> identify the runtime type. I believe even 'whatis' will do this for
> you. Whichever debugger you're using must have an understanding of the
> binary's ABI to debug C++ anyway...
Requiring that the debugger know this from the ABI (rather than being
told it by the compiler) is exactly why it takes a long time for
debuggers to catch up when the compiler ABI is changed :-(
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c++/7081: DWARF enhancements for C++
@ 2002-06-20 9:46 Daniel Jacobowitz
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Jacobowitz @ 2002-06-20 9:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/7081; it has been noted by GNATS.
From: Daniel Jacobowitz <drow@mvista.com>
To: jcownie@etnus.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/7081: DWARF enhancements for C++
Date: Thu, 20 Jun 2002 12:04:59 -0400
On Thu, Jun 20, 2002 at 10:13:22AM +0100, jcownie@etnus.com wrote:
>
> >Number: 7081
> >Category: c++
> >Synopsis: DWARF enhancements for C++
> >Confidential: no
> >Severity: non-critical
> >Priority: medium
> >Responsible: unassigned
> >State: open
> >Class: change-request
> >Submitter-Id: net
> >Arrival-Date: Thu Jun 20 02:16:04 PDT 2002
> >Closed-Date:
> >Last-Modified:
> >Originator: James Cownie
> >Release: 3.1
> >Organization:
> Etnus LLC
> >Environment:
> System: Linux pc4 2.4.18 #1 Tue Apr 2 10:17:01 BST 2002 i686 unknown
> Architecture: i686
>
>
> host: i686-pc-linux-gnu
> build: i686-pc-linux-gnu
> target: i686-pc-linux-gnu
> configured with: /home1/GNU/gcc-3.1/configure
> >Description:
> 1) g++ emits classes in DWARF with the DW_TAG_structure_type rather
> than the DW_TAG_class_type which is suggested in the DWARF V3
> specification. This makes it hard for a debugger to show the type
> name correctly since it can't tell whether the class was _really_
> introduced by the class or struct keywords.
This one's true, but...
> 2) g++ does not emit any debug information for the vtable pointer in
> classes with virtual functions. It would be much nicer if this
> information were emitted (tagged with AT_artificial), since it's
> often very useful to be able to see the vtable pointer while
> debugging, as that's how one can work out which class an object
> _actually_ is when one is looking at a base class pointer.
This one isn't really necessary. The ABI specifies where the vtable
pointer will be, and GDB is quite capable of using that knowledge to
identify the runtime type. I believe even 'whatis' will do this for
you. Whichever debugger you're using must have an understanding of the
binary's ABI to debug C++ anyway...
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-06-20 16:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-20 3:06 c++/7081: DWARF enhancements for C++ jcownie
2002-06-20 9:46 Daniel Jacobowitz
2002-06-20 10:16 James Cownie
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).