This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Cross-CU C++ DIE references vs. mangling
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: archer at sourceware dot org
- Cc: Sami Wagiaalla <swagiaal at redhat dot com>, Keith Seitz <keiths at redhat dot com>
- Date: Wed, 10 Mar 2010 20:18:33 +0100
- Subject: Cross-CU C++ DIE references vs. mangling
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