Re: Removing DW_AT_MIPS_linkage_name from dwarf2read.c

[Jim Blandy <jimb at cygnus dot com>]

>  >> I'd also like to remove dwarf2read's other dependencies on
>  >> DW_AT_MIPS_linkage_name, since it's not part of the spec and takes up a
>  >> lot of space.  As it is, we rely on that attribute to find class
>  >> members, through the symbol table.  But that shouldn't be necessary;
>  >> the definitions of the members tell you what they're defining, so you
>  >> should be able to update the field/fn_field at that time.
> 
> Did you have any thoughts about this?  The way it seems to work currently,
> given a declaration in one translation unit, gdb uses the symbol to find a
> definition in another TU.  If we don't have the symbol info, gdb know how
> to find the definition.  But it seems to me that if we properly combine
> type definitions from multiple TUs, we don't need the symbol; the
> definition of a static variable (say) would update the field entry in its
> containing type with the appropriate PHYSADDR, and things would work from
> there.  But we don't currently combine separate definitions of the same
> type, do we?  The other obstacle is that dwarf2read doesn't provide any way
> to find the field entry again from the DIE, but that should be pretty
> straightforward.

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;
    zwingli:play$ make es
    gcc -g -O2 -save-temps   -c es1.c -o es1.o
    gcc -g -O2 -save-temps   -c es2.c -o es2.o
    gcc -g -O2 -save-temps es1.o es2.o -o es
    zwingli:play$ $du/gdb/gdb -nw es
    Luddite!
    To disable command-line taunts, run gdb with "-w".

    GNU gdb 4.18.1
    Copyright 1998 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "sparc-sun-solaris2.5.1"...
    (gdb) break main
    Breakpoint 1 at 0x10760: file es1.c, line 10.
    (gdb) print es1
    $1 = {noodly = 0, woodly = 0}
    (gdb) print es2
    $2 = {mud = 0}
    (gdb)

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

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?

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.  But I'd like to understand
how GDB ought to behave before we make more changes.