Example use case: glibc installs ld.so. When stripping symbols, this can throw a kink into the operation of e.g. valgrind. valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strlen valgrind: in an object with soname matching: ld-linux-x86-64.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-x86-64.so.2 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Note that if you are debugging a 32 bit process on a valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo valgrind: package (e.g. libc6-dbg:i386). valgrind: valgrind: Cannot continue -- exiting now. Sorry. Per discussion: <ztrawhcse> sam_: I feel like ld.so should never be stripped, really. <sam_> the thing is even without debugging symbols <sam_> symtab would help valgrind a lot <ztrawhcse> sam_: I guess dostrip doesn't let you pass suppression arguments to strip such as suppressing removal of symtab... <sam_> unfortunately not, although this is an interesting idea <sam_> (and perhaps one to explore for EAPI 9)
More generally, from the glibc ebuild: # Note [Disable automatic stripping] # Disabling automatic stripping for a few reasons: # - portage's attempt to strip breaks non-native binaries at least on # arm: bug #697428 # - portage's attempt to strip libpthread.so.0 breaks gdb thread # enumeration: bug #697910. This is quite subtle: # * gdb uses glibc's libthread_db-1.0.so to enumerate threads. # * libthread_db-1.0.so needs access to libpthread.so.0 local symbols # via 'ps_pglobal_lookup' symbol defined in gdb. # * 'ps_pglobal_lookup' uses '.symtab' section table to resolve all # known symbols in 'libpthread.so.0'. Specifically 'nptl_version' # (unexported) is used to sanity check compatibility before enabling # debugging. # Also see https://sourceware.org/gdb/wiki/FAQ#GDB_does_not_see_any_threads_besides_the_one_in_which_crash_occurred.3B_or_SIGTRAP_kills_my_program_when_I_set_a_breakpoint # * normal 'strip' command trims '.symtab' # Thus our main goal here is to prevent 'libpthread.so.0' from # losing it's '.symtab' entries. # As Gentoo's strip does not allow us to pass less aggressive stripping # options and does not check the machine target we strip selectively. The last two lines here are key.
Implementing MiniDebugInfo would make this partly, if not entirely, obsolete as it preserves symtab (bug 938762).