Re: Finding ld.so dynamic loader

Michael Eager
2008-01-30T18:31:50Z

Daniel Jacobowitz wrote:
> On Wed, Jan 30, 2008 at 09:00:35AM -0800, Michael Eager wrote:
>> IMO, if this prefix is not set by the user, the environment
>> symbol or path should be searched, with the host system searched
>> as a final choice. I can create a patch to do this if desired.
>
> It's harder than it sounds to figure out whether we're native
> debugging or remote debugging once you're down in the shared library
> code; I don't think it's worth it. I have no preference whether we
> search the solib-search-path before or after the sysroot, though I am
> a little worried about breaking existing setups...

There's a chain of calls from remote_open() to enable_break()
to solib_open(). It would be possible to set a global flag
(arrgh!) in remote_open() which could be checked in solib_open().
It would also seem reasonable to have a flag set in the gdb-arch
code to say not to search host system directories.

Somewhere along the way the principle of least surprise should
kick in. I only noticed this because my target has a dynamic
loader named "/lib/ld.so.1". If it had been "/lib/ld-linux.so.2"
then gdb would have quietly placed a breakpoint on the target
at whatever location would be correct on the host system.