Re: debugging in-build-tree glibc

[Daniel Jacobowitz <drow at false dot org>]

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