Re: Cross solib support; continued

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Nov 08, 2001 at 04:24:16PM +0100, Orjan Friberg wrote:
> A couple of more questions regarding support for cross solibs:
> 
> 1. I need some way to make gdb not care about the path to a solib, i.e.
> ignore "/lib" when searching for "/lib/libc.so.6".  This is because the
> directory where the unstripped solibs reside isn't called "lib".  In
> effect, I'm grabbing the unstripped solibs from the compiler's include
> directories instead of from (a copy of) the target's file system (since
> those solibs are stripped).  Nope, can't have unstripped solibs on the
> target.
> 
> That is, I would like a solib that is now searched for in
> solib-absolute-prefix to be searched for in solib-search-path instead. 
> Would it make sense to add such a command, like solib-ignore-path?  (I'd
> be happy to make it happen.)  In effect, it would make all solibs to be
> searched for in solib-search-path by file name only, and
> solib-absolute-path would have no effect.

Is this really necessary?  I just put unstripped libraries in a
directory named lib and set the absolute prefix appropriately.

Other than that, we should fall back to solib-search-path and the
basename if solib-absolute-path fails for us, IMO.  Would that work for
you?  Set the absolute-path to /dev/null or so and then add the
fallback code.

> 2. With a work-around for the directory problem above, when I start the
> program under the gdbserver I get hold of it in _start in ld.so.1, but
> the symbols for ld.so.1 aren't loaded.  More specifically, I can't "list
> _start" and backtrace gives me "#0  0x1aaadc34 in ?? ()".  I assume this
> is because gdb hasn't had a chance to put a breakpoint in ld.so.1 that
> would make it know about the loading of it.  Chicken-egg problem, but
> not really a problem; few developers will ever have to debug glibc's
> startup routines.  I just wanted to check I understand the limitations
> correctly.  (The stuff in ld.so.1 is loaded by the time I get to main,
> so that part works.)

Wait... something doesn't sound quite right.  First of all, _start is a
symbol in the executable, not in ld.so.1.  Can you look at _dl_start?

The symbols must be loaded (via the .interp and the absolute path) or
we could not set the breakpoint.

... wait, no, that just means we need to find the linker so that we can
open it and read minsyms.  You're right, no symbols yet.  You can
probably add them with add-symbol-file, though.  Then you can step to
debug the startup code, and may be able to set breakpoints.  GDB does
tend to get a little confused here, though.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer