Re: solib-search-path not honoured after program start

[Kevin Buettner <kevinb@redhat.com>]

On Feb 19,  2:04pm, Kris Warkentin wrote:

> Here's the problem:
> 
> Run a program under gdb and break at main.  If gdb can't find all the shared
> libs, it complains about it like so:
> 
> Error while mapping shared library sections:
> libtestLib_g.so.1: No such file or directory.
> 
> So, at main, if I 'info shared', I see something like this:
> 
> >From        To                  Syms Read   Shared Object Library
>                                             No          libtestLib_g.so.1
> 0xb0312504  0xb0349b06  Yes         /t/x86/lib/libc.so.2
> 
> If I now go and set solib-search-path such that it can find
> libtestLib_g.so.1, and type 'shared', it still doesn't find it.
> 
> If I restart the program, there is no problem.  For whatever reason, after
> the process has started, gdb never tries to find the shlibs again.
> 
> I spent some time tracing around but didn't see exactly where this might be
> fixable.  Looks like solib_open does the searching but isn't called later
> on.  The shared command calls solib_add which doesn't seem to do any
> searching on solib_search_path.
> 
> Can/should this be fixed?

I think this so.

At first glance, the problem seems to be that update_solib_list() only
considers mapping newly found shared libraries and not ones that were
previously known, but which could not be found.

It might not be too hard to change things so that it attempts to map
previously unmappable libraries, but I wonder what should happen to
already mapped and/or loaded shared libraries when solib-search-path
is changed.  If changing the search path (or the absolute prefix)
would cause different libraries to be found (than were found
previously), should the old ones be unmapped/discarded?  (I suspect
the answer is yes.)

If so, maybe the right way to fix this problem is to have the
"set solib-search-path" and "set solib-absolute-prefix" commands
simply unload all known shared libraries and then invoke solib_add().

Kevin