From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2331 invoked by alias); 10 Mar 2010 19:18:49 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 2319 invoked by uid 22791); 10 Mar 2010 19:18:47 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Date: Wed, 10 Mar 2010 19:18:00 -0000 From: Jan Kratochvil To: archer@sourceware.org Cc: Sami Wagiaalla , Keith Seitz Subject: Cross-CU C++ DIE references vs. mangling Message-ID: <20100310191833.GA2816@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-08-17) X-SW-Source: 2010-q1/txt/msg00090.txt.bz2 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 ... (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