This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: debugging in-build-tree glibc
On Sat, Apr 09, 2005 at 06:35:41PM -0700, Roland McGrath wrote:
> > Currently I just run /path/to/build-$(PLATFORM)/elf/ld-linux.so.2
> > directly under GDB and replicate the --library-path, executable
> > path, et al. arguments that the build itself uses.
>
> Btw, testrun.sh in the build directory exists to make those options easy to
> find.
>
> > This allows me to debug but since we're debugging ld.so directly
> > the loading of new files does not get caught by gdb so no symbol
> > information is available for anything outside of ld.so itself.
> > If I really need the symbol information I look at the output of
> > /proc/${PID-of-ld-linux.so.2}/maps and lookup the symbol names
> > manually. To say the least, this is cumbersome...
>
> I often wind up doing the same thing, but I use gdb's add-symbol-file
> command. It's a little cumbersome in that you have to figure out the vma
> of .text in the .so file (with objdump or readelf or whatnot), add the
> mapping address to yield the runtime address of its .text, and give the
> resulting number in the second argument to add-symbol-file. But that's
> less cumbersome than converting addresses by hand.
Here's a less cumbersome method: start gdbserver and two GDBs. Then
you connect one of the GDBs with ld.so loaded, and continue to
somewhere after the application itself is loaded (_dl_debug_state will
do fine if you aren't debugging early initialization), and use the
disconnect command. Then start another GDB with the application
loaded, and connect. I occasionally use solib-absolute-prefix pointed
at a mock install tree to make GDB find the 'right' ld.so, so that it
can track dynamic loading.
If you have a idea of desirable interface for GDB in order to do this
more straightforwardly, let me know, and we can probably implement it.
--
Daniel Jacobowitz
CodeSourcery, LLC