The implementation for "debug" symbols for system libraries is incomplete. Problem #1: Even with the debug symbols (-ggdb when emerging) in /usr/lib/debug/... there is still a problem accessing the source code/files. For example, one cannot set a breakpoint at malloc() in glibc and get a list the malloc function. The .debug files do not appear to contain the source code and the source code for glibc is deleted from PORTAGE_TMPDIR after an emerge. This can be resolved if one extracts the glibc files from the distfile archive into a "long-lived" directory, e.g. /usr/src/glibc/glibc-2.10.1, but this will not normally contain the Gentoo patches. The only way it seems to get the "real" source code is to start an emerge of glibc (which takes ~ an hour), stop it after the patches are done and then copy the patched source from PORTAGE_TMPDIR to /usr/src/glibc-2.10.1. Then one is *still* going to have to adjust gdb to see the sources, e.g. adding commands like: directory /usr/src/glibc/glibc-2.10.1/io directory /usr/src/glibc/glibc-2.10.1/libio directory /usr/src/glibc/glibc-2.10.1/malloc directory /usr/src/glibc/glibc-2.10.1/sysdeps/unix/sysv/linux/i386 to the .gdbinit startup file. There ought to be a reliable (read "less kludgy") way of doing this as it gets rather tedious when it involves 100+ shared system libraries as is the case when debugging galeon, firefox, etc. Problem #2: Even with the source code access resolved there are still some functions which are not handled correctly. For example, when debugging glibc functions, and with the source access fixed as described above, I can get source listings for malloc.c, socket.S, etc. but I cannot get listings for files/functions which appear to involve "weak" bindings, e.g. .../io/open.c, .../io/read.c, .../misc/select.c, etc. which makes it very hard to set breakpoints in those functions only at points in the code where errors are being returned, certain file descriptors are being accessed, etc. Reproducible: Always Steps to Reproduce: 1. Build glibc with -ggdb. Build a test program (the examples from getaddrinfo(3) might be useful if adjusted to malloc() some of the data structures). 2. Set breakpoints at malloc, socket, bind, recvfrom, sendto, etc. 3. See which functions provide argument name info on backtraces and/or which can produce source listings. Actual Results: Functions with weak bindings do not appear to provide argument information or source listings. Expected Results: All source files as well as function, argument and local symbols should be available when programs and libraries are built for debugging.
for the first issue, FEATURES=installsources (see man 5 make.conf) may be what you're looking for. it requires dev-util/debugedit be installed.
I am still in the midst of recompiling a large chunk of the system after following Remi's instructions for upgrading libxcb. Preliminary tests seem to indicate that the "installsources" FEATURES option does what I want. It would be *nice* if the documentation actually said "what" it does. Currently it appears that the source is somehow packaged into the package.debug files in /usr/lib/debug. (Is there a special section in the debug files for package source? Is the source compressed in any way? Can gdb deal with compressed .debug files (e.g. package.debug.bz2)?) However the same preliminary tests seem to indicate that Problem #2 still exists. If I compile a very simple program with dummy calls to malloc() and read(), and set breakpoints at those functions, I can "list malloc" but not "list read". so there is still something wrong with building glibc for debugging.
the make.conf man page already documents the two relevant FEATURES as for inability to poke glibc internals, things are compiled with optimization and misbehavior is the norm
