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.