Bug#721383: libc6: Debug information for ld*.so routines are not available even if I install libc6-dbg.
Package: libc6
Severity: normal
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***
* What led up to the situation?
Trying to use valgrind under amd64 version.
Then valgrind complained at the startup that ld*.so is stripped
and some symbols could not be found.
I am using a memory usage checker, valgrind, and
hit into a problem of symbols of ld.so not found.
Exactly speaking it is not ld.so, but /lib64/ld-2.17.so,
and eventually /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
Although I installed libc6-dbg package, the
debug symbols for ld*.so are not there, it seems.
I think the missing debug symbol problem was fixed on i386 (32bit)
Debian GNU/Linux by installing debug symbol package(s) for run-time
libraries, but I am not sure how to fix this on amd64 architecture
distribution.
Maybe the package for amd64 do lack the necessary debug information in
the offered package.
So please
- provide the necessary debug infomration for ld*.so file, or
- if it *IS* available, please make it easy for users to find it.
The reason why valgrind needs unstripped ld.so
(/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2) is as follows.
I am quoting this from
http://valgrind.org/docs/manual/dist.readme-packagers.html
valgrind's search for strlen() is actually furtile since the latest
gcc seems to replace calls to strlen() with inlined version, but it
also searches other symbols, so it is useful to find a list of symbols
there (at least the entry point names).
--- begin quote ---
-- Do not ship your Linux distro with a completely stripped
/lib/ld.so. At least leave the debugging symbol names on -- line
number info isn't necessary. If you don't want to leave symbols on
ld.so, alternatively you can have your distro install ld.so's
debuginfo package by default, or make ld.so.debuginfo be a
requirement of your Valgrind RPM/DEB/whatever.
Reason for this is that Valgrind's Memcheck tool needs to intercept
calls to, and provide replacements for, some symbols in ld.so at
startup (most importantly strlen). If it cannot do that, Memcheck
shows a large number of false positives due to the highly optimised
strlen (etc) routines in ld.so. This has caused some trouble in
the past. As of version 3.3.0, on some targets (ppc32-linux,
ppc64-linux), Memcheck will simply stop at startup (and print an
error message) if such symbols are not present, because it is
infeasible to continue.
It's not like this is going to cost you much space. We only need
the symbols for ld.so (a few K at most). Not the debug info and
not any debuginfo or extra symbols for any other libraries.
--- end quote ---
Incidentally, the same web page mentions that
testing valgrind package can be done by running a large program like
firefox or openoffice under it. I am running mozilla thunderbird which
is as large and it seems to push the envelope of the program(s) and
the system itself. A very good exercise to find a bottleneck in the
system.
TIA
* What exactly did you do (or not do) that was effective (or
ineffective)?
I installed a few debug symbol package such as libc6-dbg, but
still no luck.
* What was the outcome of this action?
ld*.so seem to be stripped and valgrind could not start.
* What outcome did you expect instead?
I hoped that at least a few ld*.so files would have minimum list
of debug symbols (at least the entry points).
*** End of the template - remove these lines ***
-- System Information:
Debian Release: jessie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Reply to: