Cross-CU C++ DIE references vs. mangling

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

Hi,

wrt discussion on ignoring DW_AT_MIPS_linkage_name at all:

namespace S { extern int i; };
int *p = &S::i;

generates (4.5.0 20100310 (experimental)):
$ nm
                 U _ZN1S1iE
0000000000000000 D p
$ nm -C
                 U S::i
0000000000000000 D p
$ readelf -wi
# Simplified.
 <1><4e>: Abbrev Number: 5 (DW_TAG_namespace)
    <4f>   DW_AT_name        : S        
 <2><53>: Abbrev Number: 6 (DW_TAG_variable)
    <54>   DW_AT_name        : i        
    <58>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x32): _ZN1S1iE   
    <5c>   DW_AT_type        : <0x47>   
    <60>   DW_AT_external    : 1        
    <61>   DW_AT_declaration : 1        

So GDB has to know the "S::i"->"_ZN1S1iE" mangling rules if there would be no
DW_AT_MIPS_linkage_name.  Just in this case GDB will find out "S::i" in the
defining CU (or shared library) and it can completely ignore this declaration.


So there is a countercase where GDB cannot ignore such declaration-only DIE
(and it is AFAIK the only requirement for GDB internal LOC_UNRESOLVED type):
namespace S
  {
    int f ()
      {
        int i = 42;
        {
          extern int i;
          return i;
        }
      }
  }

generates (4.5.0 20100310 (experimental)):
$ nm
0000000000000000 T _ZN1S1fEv
                 U _ZN1S1iE
$ nm -C
0000000000000000 T S::f()
                 U S::i
$ readelf -wi
# Grossly simplified.
 <1><2d>: Abbrev Number: 2 (DW_TAG_namespace)
    <2e>   DW_AT_name        : S        
 <2><36>: Abbrev Number: 3 (DW_TAG_subprogram)
    <37>   DW_AT_external    : 1        
    <38>   DW_AT_name        : f        
    <3c>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x49): _ZN1S1fEv  
    <61>   DW_AT_low_pc      : 0x0      
    <69>   DW_AT_high_pc     : 0x13     
    <71>   DW_AT_frame_base  : 0x0      (location list)
 <3><75>: Abbrev Number: 7 (DW_TAG_lexical_block)
    <76>   DW_AT_low_pc      : 0x4      
    <7e>   DW_AT_high_pc     : 0x11     
 <4><86>: Abbrev Number: 8 (DW_TAG_variable)
    <87>   DW_AT_name        : i        
    <8f>   DW_AT_location    : 2 byte block: 91 6c      (DW_OP_fbreg: -20)
 <4><92>: Abbrev Number: 9 (DW_TAG_lexical_block)
    <93>   DW_AT_low_pc      : 0xb      
    <9b>   DW_AT_high_pc     : 0x11     
 <2><45>: Abbrev Number: 4 (DW_TAG_variable)
    <46>   DW_AT_name        : i        
    <4a>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x40): _ZN1S1iE   
    <52>   DW_AT_external    : 1        
    <53>   DW_AT_declaration : 1        

This dump is wrong, last DIE should have been <5><45>: ... = new PR debug/43325.

This is just a C++ variant of the testcase gdb.dwarf2/dw2-unresolved*.


I was suggesting to use DW_FORM_ref_addr referencing global artifical symbols
like <prefix>.<file-designator>.<gid-number>.<die-number> (as described by
DWARF).  But I see now such reference is mostly just a different form of
something like DW_AT_MIPS_linkage_name so it may be no win.  Roland McGrath
said on it:

(2009-12-11 23:20:32) keiths: Right now for C++, minimal symbols are used to resolve all symbol references to addresses. (Unlike in C, where the actual symtab is used.) That's a side affect of how gdb's C++ support has been written. [This is all fixed by my dwarf2_physname patch.]
(2009-12-11 23:35:36) jkratoch: and minimal symbols are used for referencing DW_AT_location from different CU.  I would think such DW_AT_location should exist in the non-defining CU with a relocation record - so that DWARF has no dependency on ELF.
(2009-12-11 23:36:32) roland: but then it would have a different hairy kind of dependency on ELF, i.e. relocation 
(2009-12-11 23:41:15) jkratoch: OK, that makes sense, thanks, such a longterm issue I had.


Regards,
Jan