From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16857 invoked by alias); 23 Apr 2010 19:04:47 -0000 Received: (qmail 16796 invoked by uid 48); 23 Apr 2010 19:04:46 -0000 Date: Fri, 23 Apr 2010 19:04:00 -0000 From: "jan dot kratochvil at redhat dot com" To: gdb-prs@sourceware.org Message-ID: <20100423190444.11534.jan.kratochvil@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug symtab/11534] New: GDB ignores non-first symbol DIEs X-Bugzilla-Reason: CC Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2010-q2/txt/msg00155.txt.bz2 echo 'namespace N { int v = 1; }' | g++ -nostdlib -o vv -g -x c++ - objcopy -N _ZN1N1vE vv gdb -nx -q -ex 'p N::v' -ex q ./vv Address of symbol "N::v" is unknown. Why? There is DW_AT_location containing the address: <1><29>: Abbrev Number: 2 (DW_TAG_namespace) <2a> DW_AT_name : N <2><32>: Abbrev Number: 3 (DW_TAG_variable) <33> DW_AT_name : v <37> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x5a): _ZN1N1vE <3f> DW_AT_external : 1 <40> DW_AT_declaration : 1 <1><49>: Abbrev Number: 5 (DW_TAG_variable) <4a> DW_AT_specification: <0x32> <4e> DW_AT_location : 9 byte block: 3 e8 0 60 0 0 0 0 0 (DW_OP_addr: 6000e8) Question: Is it valid to specifify both DW_AT_external and DW_AT_location without any ELF symbol for it? It seems to be DWARF standard compliant. Currently GDB takes only the first DIE definition of symbol. It is because finish_block is careful to create symbol table in the read-in order and later lookup functions only find the first symbol present. Therefore DIE 0x49 gets ignored. Therefore GDB creates LOC_UNRESOLVED symbol and later resolves it via the ELF symbol table. According to DWARF4 "2.13.2 Declarations Completing Non-Defining Declarations" keyword "earlier" GDB should use only the last DIE specifying a symbol to intepret the most complete symbol DIE. We must not change dict_create_linear order as it would change at least the function parameters order (a, b) to (b, a). Changing the dict_create_hashed order seems to do the right thing. Just that moment we break copy-relocations, tested by new attached gdb.base/shlib-copy-reloc.exp We should not interpret DW_AT_location for DIEs with DW_AT_external as in such case we should prefer the ELF symbol - possibly the copy relocation from different objfile. More details on this subject by Roland McGrath: Re: Cross-CU C++ DIE references vs. mangling http://sourceware.org/ml/archer/2010-q1/msg00092.html DWARF standard does not seem to indicate anything about ignoring DW_AT_location when DW_AT_external is present; DW_AT_location probably should not be present. Attached patch starts ignoring DW_AT_location for for DIEs with DW_AT_external. GCC seems to workaround GDB by providing the two DIEs (0x32 and 0x49) using DW_AT_specification. It could simply provide a single merged DIE instead. There is a problem with gfortran as it does not provide this GDB workaround. There is GCC PR debug/40040. Roland's GCC PR debug/40040 Comment 4 suggests how to drop any ELF dependencies (requiring a mangling logic) by providing self-contained GOT-referencing DWARF expressions. -- Summary: GDB ignores non-first symbol DIEs Product: gdb Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: symtab AssignedTo: unassigned at sourceware dot org ReportedBy: jan dot kratochvil at redhat dot com CC: gdb-prs at sourceware dot org GCC target triplet: x86_64-unknown-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=11534 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.