This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: DWARF-2, static data members
- From: Jim Blandy <jimb at zenia dot red-bean dot com>
- To: David Carlton <carlton at math dot stanford dot edu>
- Cc: gdb <gdb at sources dot redhat dot com>
- Date: 13 Aug 2002 15:38:59 -0500
- Subject: Re: DWARF-2, static data members
- References: <15700.15818.829204.767503@jackfruit.Stanford.EDU>
I agree with your reading. There should be *two* entries for a C++
static data member: one as a variable definition, DW_TAG_variable, at
the top level, and one as a member definition, DW_TAG_member, as a
child of the struct/class/union die.
This sort of corresponds to the way you have to actually declare a
static member in C++. In the class definition you say:
class C
{
static int foo;
}
and then somewhere else you must actually give the definition of C::foo:
int C::foo;
For what it's worth, the paragraph of the Dwarf 2 spec that
corresponds to paragraph 6. in Section 4.1 of Draft 3 rev 7 (what I
treat as authoritative for Dwarf 3) doesn't specify what tag the type
die's child is supposed to have. I guess the entire GNU toolchain
just guessed wrong.
> Having said all that, when I run GDB on some code with static data
> members that I'd compiled with GCC 3.1, the appropriate branches were
> taken. Which means that either there's something I _really_ don't
> understand about GDB's code (always a possibility!) or else GCC is
> making the same misinterpretation and GDB.
Have you run `readelf -wi' on the executable, or run GCC with
`-save-temps -dA' and looked at the .s file, to see what GCC is
actually generating? I think GCC does generate children of
struct/class types with the DW_TAG_variable tag.
> Nonetheless, I think they should both be fixed. It seems to me that
> the safe thing to do would be to modify GDB so that it treats members
> that either are DW_TAG_variable or DW_TAG_member + DW_AT_declaration
> as static data members; that way it will be safe both with code
> compiled by current versions of GCC and by code compiled with
> hypothetical future versions of GCC that have this misinterpretation
> fixed (as well as other compilers out there that might do the right
> thing). I'd be happy to try to make this change if other people agree
> with me.
That sounds right to me.
You might put together a fix for GCC, too --- dwarf2out.c is big, but
it doesn't seem too bad. This would allow you to actually test your
changes.