Re: DWARF-2, static data members

[Jim Blandy <jimb at zenia dot red-bean dot com>]

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.