Comment # 7 on bug 1203497 from Michael Matz

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.

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.