public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug symtab/26834] New: [gsplit-dwarf] Sharing .debug_line entry between CUs results in too many symtabs Date: Mon, 02 Nov 2020 19:23:09 +0000 [thread overview] Message-ID: <bug-26834-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=26834 Bug ID: 26834 Summary: [gsplit-dwarf] Sharing .debug_line entry between CUs results in too many symtabs Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: symtab Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider test-case gdb.dwarf2/fission-multi-cu.exp. The exec and .dwo files are generated from a .S that is supposed to represent how clang -flto -gsplit-dwarf -g generates code. Something seems to be off in the way that symtabs are read in: ... $ gdb -batch \ -iex "set debug-file-directory ./outputs/gdb.dwarf2/fission-multi-cu" \ outputs/gdb.dwarf2/fission-multi-cu/fission-multi-cu \ -ex start \ -ex "b func" \ -ex "maint info symtabs" Temporary breakpoint 1 at 0x4004d9: file fission-multi-cu2.c, line 24. Temporary breakpoint 1, main () at fission-multi-cu2.c:24 24 fission-multi-cu2.c: No such file or directory. Breakpoint 2 at 0x4004b7: file fission-multi-cu1.c, line 21. { objfile fission-multi-cu ((struct objfile *) 0x21280f0) { ((struct compunit_symtab *) 0x2444ec0) debugformat DWARF 2 producer clang version 5.0.0 (trunk 302855) (llvm/trunk 302853) dirname /tmp/src/gdb/testsuite blockvector ((struct blockvector *) 0x2445490) user ((struct compunit_symtab *) (null)) { symtab fission-multi-cu1.c ((struct symtab *) 0x2444f50) fullname /tmp/src/gdb/testsuite/fission-multi-cu1.c linetable ((struct linetable *) 0x2445520) } { symtab fission-multi-cu2.c ((struct symtab *) 0x2444f80) fullname (null) linetable ((struct linetable *) 0x24454c0) } } { ((struct compunit_symtab *) 0x23ecb20) debugformat DWARF 2 producer clang version 5.0.0 (trunk 302855) (llvm/trunk 302853) dirname /tmp/src/gdb/testsuite blockvector ((struct blockvector *) 0x2444da0) user ((struct compunit_symtab *) (null)) { symtab fission-multi-cu2.c ((struct symtab *) 0x23ecbe0) fullname (null) linetable ((struct linetable *) 0x2444e40) } { symtab fission-multi-cu1.c ((struct symtab *) 0x23ecbb0) fullname (null) linetable ((struct linetable *) 0x2444dd0) } } } ... Both fission-multi-cu1.c and fission-multi-cu2.c appear twice, not once. In contrast, if I do: ... $ clang -g -gsplit-dwarf -flto ./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu*.c ... we get: ... $ gdb -batch \ -iex "set debug-file-directory ." \ a.out \ -ex start \ -ex "b func" \ -ex "maint info symtabs" Temporary breakpoint 1 at 0x4004b4: file ./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu2.c, line 23. Temporary breakpoint 1, main () at ./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu2.c:23 23 func (-1); Breakpoint 2 at 0x4004a7: file ./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu1.c, line 21. { objfile /home/vries/gdb_versions/devel/a.out ((struct objfile *) 0x3d3d0f0) { ((struct compunit_symtab *) 0x4055d70) debugformat DWARF 2 producer clang version 10.0.1 dirname /home/vries/gdb_versions/devel blockvector ((struct blockvector *) 0x4056310) user ((struct compunit_symtab *) (null)) { symtab ./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu1.c ((struct symtab *) 0x4055e00) fullname /home/vries/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.dwarf2/fission-multi-cu1.c linetable ((struct linetable *) 0x4056340) } } { ((struct compunit_symtab *) 0x4001ac0) debugformat DWARF 2 producer clang version 10.0.1 dirname /home/vries/gdb_versions/devel blockvector ((struct blockvector *) 0x4055cc0) user ((struct compunit_symtab *) (null)) { symtab ./src/gdb/testsuite/gdb.dwarf2/fission-multi-cu2.c ((struct symtab *) 0x4001b50) fullname /home/vries/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.dwarf2/fission-multi-cu2.c linetable ((struct linetable *) 0x4055cf0) } } } ... A difference between the two is that in the former case the same .debug_line bit is used for both CUs: ... Offset: 0xe9 ... The File Name Table (offset 0x105): Entry Dir Time Size Name 1 0 0 0 fission-multi-cu1.c 2 0 0 0 fission-multi-cu2.c ... and in the latter case each CU has it's own .debug_line bit: ... Offset: 0xe9 ... The Directory Table (offset 0x105): 1 ./src/gdb/testsuite/gdb.dwarf2 The File Name Table (offset 0x125): Entry Dir Time Size Name 1 1 0 0 fission-multi-cu1.c Offset: 0x15b ... The Directory Table (offset 0x177): 1 ./src/gdb/testsuite/gdb.dwarf2 The File Name Table (offset 0x197): Entry Dir Time Size Name 1 1 0 0 fission-multi-cu2.c ... -- You are receiving this mail because: You are on the CC list for the bug.
reply other threads:[~2020-11-02 19:23 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-26834-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).