[Bug 1203497] New: Strip glibc ojbects debuginfo
https://bugzilla.suse.com/show_bug.cgi?id=1203497 Bug ID: 1203497 Summary: Strip glibc ojbects debuginfo Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs@suse.de Reporter: tdevries@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- openSUSE is a bit unusual in that a hello world compiled without debuginfo still contains debug info: ... $ gcc ~/hello.c $ readelf -S -W a.out | grep debug [28] .debug_aranges PROGBITS 0000000000000000 001060 000100 00 0 0 16 [29] .debug_info PROGBITS 0000000000000000 001160 000269 00 0 0 1 [30] .debug_abbrev PROGBITS 0000000000000000 0013c9 000183 00 0 0 1 [31] .debug_line PROGBITS 0000000000000000 00154c 0001e7 00 0 0 1 [32] .debug_str PROGBITS 0000000000000000 001733 000435 01 MS 0 0 1 [33] .debug_loc PROGBITS 0000000000000000 001b68 00013e 00 0 0 1 [34] .debug_ranges PROGBITS 0000000000000000 001cb0 000080 00 0 0 16 ... This is due to linked-in glibc objects which contain debug info: ... $ readelf -S -W a.out | grep debug [28] .debug_aranges PROGBITS 0000000000000000 001060 000100 00 0 0 16 [29] .debug_info PROGBITS 0000000000000000 001160 000269 00 0 0 1 [30] .debug_abbrev PROGBITS 0000000000000000 0013c9 000183 00 0 0 1 [31] .debug_line PROGBITS 0000000000000000 00154c 0001e7 00 0 0 1 [32] .debug_str PROGBITS 0000000000000000 001733 000435 01 MS 0 0 1 [33] .debug_loc PROGBITS 0000000000000000 001b68 00013e 00 0 0 1 [34] .debug_ranges PROGBITS 0000000000000000 001cb0 000080 00 0 0 16 ... This caused quite a few FAils in the gdb testsuite, that are all fixed by now, but ... In tumbleweed, we now have a ctf-capable gcc compiler, and all ctf-related tests in the testsuite are failing, due to upstream PR https://sourceware.org/bugzilla/show_bug.cgi?id=29160 . Basically the problem is that gdb doesn't handle an object with both dwarf and ctf info, or rather, it gives priority to the dwarf info and ignores the ctf info. I could try to fixup the testsuite, but at this point I think it's better to either strip the glibc objects, or make it optional. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1203497
Chenzi Cao
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c1
Andreas Schwab
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c2
--- Comment #2 from Tom de Vries
glibc cannot be stripped due to libthread_db.
Can you explain what is special about libthread_db in opensuse that makes that that debuginfo is needed, because pretty much all other distribution don't have this debuginfo. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c3
--- Comment #3 from Tom de Vries
https://bugzilla.suse.com/show_bug.cgi?id=1203497
Martin Jambor
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c4
--- Comment #4 from Tom de Vries
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c5
Tom de Vries
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c6
--- Comment #6 from Richard Biener
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c7
--- Comment #7 from Michael Matz
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c8
--- Comment #8 from Tom de Vries
So, it's indeed the case that glibc _generally_ can't be stripped, due to libthread_db needing the .symtab (not just .dynsym) from libpthread.so to access some internal symbols of it. Here's my old comment from 2005 in glibc.spec:
-------------------- # We don't want to strip the .symtab from our libraries in find-debuginfo.sh, # certainly not from libpthread.so.* because it is used by libthread_db to find # some non-exported symbols in order to detect if threading support # should be enabled. These symbols are _not_ exported, and we can't easily # export them retroactively without changing the ABI. So we have to # continue to "export" them via .symtab, instead of .dynsym :-( # But we also want to keep .symtab and .strtab of other libraries since some # debugging tools currently require these sections directly inside the main # files - specifically valgrind and PurifyPlus. export STRIP_KEEP_SYMTAB=*.so* --------------------
So, .symtab should stay in the libraries.
Ack, thank you for the clear explanation, now I understand what Andreas was referring to.
Now, the question _here_ is about the crt files, i.e. {M,S,g,gr,r,}crt1.o and crt[1in].o, and about the ones in the static archives. Technically those could be stripped from debug info, AFAIK. (The .symtab will have to stay in .o files of course)
But: I do think that gdb needs to eventually deal with this situation. If this problem already arises in the testsuite (gdb not correctly handling mixed dwarf and ctf debug info) then it will also arise in other uses. People might have 3rdparty objects (libs or .o) that contains random debug info and might want to compile their own project with $other debug info. So, as you asked for preferences: glibc shouldn't be changed to accomodate this gdb problem.
Right, I understand your point. My take on this is that I'm not asking to accommodate a gdb problem, but rather the SUSE gdb maintainer. Having this extra debug info puts me into a position of being the only one in the gdb community who addresses problem in the test-suite related to this. That had its use when there lots of FAILs and problems were or might have been lurking, but that has run its course (hence my decision to file this PR), and at this point the extra debug info is just something that keeps volunteering me for extra work. So, does gdb eventually need to deal with this? Perhaps, perhaps not. I prefer to let this lie until someone actually needs it, or somebody else implements it. But I want the testsuite clean, so I'll have to do the extra work of implementing a workaround at the very least. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c9
--- Comment #9 from Richard Biener
gcc t.c -gctf -gdwarf -c readelf -S t.o | grep 'ctf\|debug' [ 5] .ctf PROGBITS 0000000000000000 000001a2 [ 7] .debug_info PROGBITS 0000000000000000 00000a78 [ 8] .rela.debug_info RELA 0000000000000000 000015f0 [ 9] .debug_abbrev PROGBITS 0000000000000000 00000d28 [10] .debug_aranges PROGBITS 0000000000000000 00000e2e [11] .rela.debug_[...] RELA 0000000000000000 00001db8 [12] .debug_line PROGBITS 0000000000000000 00000e60 [13] .rela.debug_line RELA 0000000000000000 00001de8 [14] .debug_str PROGBITS 0000000000000000 00000f28 [15] .debug_line_str PROGBITS 0000000000000000 000010d8
that's an intended feature btw. I don't quite understand why gdb cannot handle both CTF and DWARF at the same time but eventually it's hard to distinguish the cases of having both CTF and DWARF for the same CU vs. having only DWARF or CTF (knowing nothing of CTF, aka whether comparing address-ranges or source file names or some other mechanism could handle this). IIRC the link editor also does some magic in "merging" actual CTF data. Maybe we need some extension like a DW_AT_ctf pointing to CTF of a DWARF CU to help gdb here. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1203497
Tom de Vries
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c10
--- Comment #10 from Tom de Vries
I don't quite understand why gdb cannot handle both CTF and DWARF at the same time
The common use case for ctf is to be used when dwarf is not available, and not to be used when dwarf is available (assuming they contain roughly the same scope of info, but with the dwarf one more detailed than the ctf one), and that idea was also implemented in gdb. To put it more concretely: it's targeted at a distro with optional separate dwarf debug-info. If the dwarf debug-info is installed (or downloaded), use it. If not, use the ctf (also tools may opt to ignore the dwarf and read ctf out of speed/memory concerns, but that's more the domain of non-debugger readers). I rfc-ed a patch ( https://sourceware.org/pipermail/gdb-patches/2022-September/192044.html ) that introduces a command to control symbol reading order, where the default is reflected by: ... (gdb) maint set symbol-read-order mdebug+stabs+dwarf2/ctf ... meaning don't read ctf if dwarf2 is present. Then, by using ... (gdb) maint set symbol-read-order ctf ... I can make the gdb test-cases pass (because there's no useful info in the dwarf, so ignoring it is fine). Reading both ctf and dwarf2 is supported by: ... (gdb) maint set symbol-read-order dwarf2+ctf ... or the opposite order, which seems to work ok for disjunct scope, in the test-case I added. But I think I'm the first to try this out, so there may be problems lurking. I have no idea what happens for overlapping scope. This used to be predictable when dwarf got translated into partial symbol tables, the same as the other formats, but that's not the case anymore in gdb-13, due to the the speed improvement introduced the "cooked index". -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c11
--- Comment #11 from Tom de Vries
... (gdb) maint set symbol-read-order dwarf2+ctf ...
Anyway, if this command makes it into upstream, this is the command opensuse users will have to use to support debugging hello world with ctf: ... $ gcc -gctf ~/hello.c $ gdb -iex "maint set symbol-read-order ctf" a.out ... while on other distros we'll have: ... $ gcc -gctf ~/hello.c $ gdb a.out ... To prevent this, we can change the default for the opensuse gdb package to mdebug+stabs+ctf+dwarf2, but I don't think that's a good idea, since that will also come at a cost, and is not the right setup for debugging packages. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com