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.
