Comment # 8 on bug 1203497 from Tom de Vries

(In reply to Michael Matz from comment #7)
> 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.