Re: Removing DW_AT_MIPS_linkage_name from dwarf2read.c

[Jason Merrill <jason at cygnus dot com>]

>>>>> Jim Blandy <jimb@cygnus.com> writes:

 > GDB doesn't unify types because (as far as I know) this is valid C:

 >     zwingli:play$ cat es1.c
 >     struct foo {
 >       int noodly;
 >       int woodly;
 >     };

 >     struct foo es1;

 >     main ()
 >     {
 >     }
 >     zwingli:play$ cat es2.c
 >     struct foo {
 >       int mud;
 >     };

 >     struct foo es2;

I believe you are correct.

 > I don't know C++ very well at all.  Does C++ specify stricter rules
 > about type agreement between compilation units?

Yes.  The C++ One Definition Rule basically says that classes with the same
name in different translation units must be equivalent.  See

  http://www.cygnus.com/iso/wp/html/fdis/basic.html#basic.def.odr

for the (rather legalistic) details.

 > If I create a header file which declares a class with a private static
 > member, and then I #include that header in two .cc files, and then
 > link those two .cc files together, do both members refer to the same
 > storage?

Yes.  They would have to, since mangling would work the same for both TUs.
The stricter rules in C++ basically follow from the addition of static data
members and member functions.

 > Anyway, the general principle is that GDB should follow the same rules
 > the rest of the toolchain does.  Usually, these end up relying on
 > something's external linkage name, so I'm not entirely surprised that
 > the concept shows up in the debug info.

Nor am I, but that's not how dwarf is supposed to work.  Of course, SGI
doesn't DTRT here either; that's where we got DW_AT_MIPS_linkage_name from
in the first place.  Of course, they seem to make no attempt to connect
declaration and definition, and don't even mention member functions in the
class info, so they aren't really a shining example of dwarf2 usage.

Jason