From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 69E9F385DC00; Wed, 1 Apr 2020 21:51:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69E9F385DC00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1585777889; bh=08nR2EbzOcGnHoBCH2+UtxlSCATkClFglVYZFYYOyXE=; h=From:To:Subject:Date:From; b=iLOEyBvaztMUpVR8w/0V/z7hNB92HNIkTWsdHtNmsmqbU9VaOSfJoP9UAmaC8cHz0 8S2A2d8MQzzipVAijuwJSQ+69g3Uc4O77MsGK+gr3qwI1HzCVblZQ8NEZpIhPWY3am a6vNW1MNKZEbOps3vixboDa7PAYz2hFzFBJ2biRc= From: "vries at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/94450] New: lto abstract variable emitted as concrete decl Date: Wed, 01 Apr 2020 21:51:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 21:51:29 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94450 Bug ID: 94450 Summary: lto abstract variable emitted as concrete decl Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider test-case test.c: ... int aaa; int main (void) { return aaa; } ... Compiled with -flto: ... $ gcc-10 -O0 test.c -g -flto -flto-partition=3Dnone -ffat-lto-objects ... The debug info for the variable aaa looks like this: ... <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_name : <1>: Abbrev Number: 2 (DW_TAG_imported_unit) DW_AT_import : <0x12b> [Abbrev Number: 1] <1>: Abbrev Number: 3 (DW_TAG_variable) DW_AT_abstract_origin: <0x13d> DW_AT_location : 9 byte block: 3 2c 10 60 0 0 0 0 0=20=20=20= =20=20=20 (DW_OP_addr: 60102c) <0><12b>: Abbrev Number: 1 (DW_TAG_compile_unit) <131> DW_AT_name : test.c <1><13d>: Abbrev Number: 2 (DW_TAG_variable) <13e> DW_AT_name : aaa <142> DW_AT_decl_file : 1 <143> DW_AT_decl_line : 1 <144> DW_AT_decl_column : 5 <145> DW_AT_type : <0x149> <149> DW_AT_external : 1 ... When printing the symbol tables in gdb: ... $ gdb -readnow -batch a.out -ex "maint print symbols" ... it turns out we have two symbols aaa, one here: ... Symtab for file test.c at 0x23aeeb0 Compilation directory is /home/vries Read from object file /home/vries/a.out (0x238cc90) Language: c Blockvector: block #000, object at 0x23af030, 1 syms/buckets in 0x0..0x0 int aaa; unresolved block #001, object at 0x23aef80 under 0x23af030, 1 syms/buckets in 0x0..0= x0 typedef int int;=20 Compunit user: 0x23aedf0 ... and one here: ... Symtab for file at 0x23aedf0 Compilation directory is /home/vries Read from object file /home/vries/a.out (0x238cc90) Language: c Blockvector: block #000, object at 0x23aecb0, 1 syms/buckets in 0x400492..0x40049e int aaa; static at 0x60102c section .bss int main(void); block object 0x23aebf0, 0x400492..0x40049e section .text block #001, object at 0x23aec50 under 0x23aecb0, 0 syms/buckets in 0x400492..0x40049e block #002, object at 0x23aebf0 under 0x23aec50, 0 syms/buckets in 0x400492..0x40049e, function main Compunit include: 0x23aeeb0 ... If we do "print aaa" in gdb and gdb finds the 'static' aaa symbol first, it uses the DW_AT_location to find the address of the variable. If we do "print aaa" in gdb and gdb finds the 'unresolved' aaa symbol first= , it looks in the minimal symbols for a symbol aaa and uses that address. In both cases, we'd find the same address and print the same value, so ther= e's no correctness problem for this example. But with ada, we run into PR gdb/25760 - "[gcc -flto] FAIL: gdb.ada/call_pn.exp: print last_node_id after calling pn (timeout)", which means that there is a correctness problem. It's an idea to try to ignore these useless decls in gdb (filed as PR gdb/2= 5759 - "Remove useless decls from symtab"), but I'm not sure yet how easy it is = to do this efficiently. So, it would be good if gcc could make it explicit in the DWARF that there's only one symbol to be considered, rather than having gdb spent time to igno= re the abstract one. ISTM the only way to do this is to make the test.c CU a partial unit (using DW_TAG_partial_unit) and drop the import. [ Having said that, I'm not sure that gdb in its current state would correc= tly interpret such dwarf and only create one symbol, so that might require an additional gdb fix. ]=