public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/26834] New: [gsplit-dwarf] Sharing .debug_line entry between CUs results in too many symtabs
@ 2020-11-02 19:23 vries at gcc dot gnu.org
0 siblings, 0 replies; only message in thread
From: vries at gcc dot gnu.org @ 2020-11-02 19:23 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-11-02 19:23 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-02 19:23 [Bug symtab/26834] New: [gsplit-dwarf] Sharing .debug_line entry between CUs results in too many symtabs vries at gcc dot gnu.org
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).