solib-search-path not honoured after program start

solib-search-path not honoured after program start

[Kris Warkentin]

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?

cheers,

Kris

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

[Kevin Buettner]

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

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

[Kris Warkentin]

> 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().

What do you think of this?

$ cvs diff -c solib.c
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.53
diff -c -r1.53 solib.c
*** solib.c     18 Jan 2003 15:55:52 -0000      1.53
--- solib.c     19 Feb 2003 19:57:38 -0000
***************
*** 431,436 ****
--- 431,445 ----
        struct so_list *i = inferior;
        struct so_list **i_link = &inferior;

+       /* if this lib hasn't been read, remove it from gdb's list so
+          that we can try again */
+       if (!gdb->abfd && !gdb->objfile){
+         *gdb_link = gdb->next;
+         free_so (gdb);
+         gdb = *gdb_link;
+         continue;
+       }
+
        /* Check to see whether the shared object *gdb also appears in
         the inferior's current list.  */
        while (i)

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

[Kevin Buettner]

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

> > 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().
> 
> What do you think of this?
[patch elided]

Your patch corresponds to my "at first glance" comment above.  While
it might provide some short term relief for the problem that you're
seeing, it doesn't address the problem of libraries needing to be
reloaded when the search path or absolute prefix is changed.  Would
you mind trying the following patch instead?

	* solib.c (reload_shared_libraries): New function.
	(_initialize_solib): Add command callbacks for
	``set solib-search-path'' and ``set solib-absolute-prefix''.

Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.53
diff -u -p -r1.53 solib.c
--- solib.c	18 Jan 2003 15:55:52 -0000	1.53
+++ solib.c	19 Feb 2003 21:08:42 -0000
@@ -844,6 +844,13 @@ no_shared_libraries (char *ignored, int 
   do_clear_solib (NULL);
 }
 
+static void
+reload_shared_libraries (char *ignored, int from_tty)
+{
+  no_shared_libraries (NULL, from_tty);
+  solib_add (NULL, from_tty, NULL, auto_solib_add);
+}
+
 void
 _initialize_solib (void)
 {
@@ -873,6 +880,7 @@ inferior.  Otherwise, symbols must be lo
 For other (relative) files, you can add values using `set solib-search-path'.",
 		   &setlist);
   add_show_from_set (c, &showlist);
+  set_cmd_cfunc (c, reload_shared_libraries);
   set_cmd_completer (c, filename_completer);
 
   /* Set the default value of "solib-absolute-prefix" from the sysroot, if
@@ -885,5 +893,6 @@ For other (relative) files, you can add 
 This takes precedence over the environment variables PATH and LD_LIBRARY_PATH.",
 		   &setlist);
   add_show_from_set (c, &showlist);
+  set_cmd_cfunc (c, reload_shared_libraries);
   set_cmd_completer (c, filename_completer);
 }

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

[Kris Warkentin]

> Your patch corresponds to my "at first glance" comment above.  While
> it might provide some short term relief for the problem that you're
> seeing, it doesn't address the problem of libraries needing to be
> reloaded when the search path or absolute prefix is changed.  Would
> you mind trying the following patch instead?

It's funny because I had actually came up with that before I read your email
(hence the quick turnaround).  "Great minds think alike but fools seldom
differ."  Which were we again? ;-)

I like your patch better.  At first glance I didn't see how it would do the
trick (I thought you were just adding a command) but I guess the
set_cmd_cfunc works automatically.

Works great.  I'm going to apply it to our 5.2.1 tree as well since it
solves an internal problem we're having.  Thanks a lot.

cheers,

Kris

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

[Kevin Buettner]

On Feb 19,  2:11pm, Kevin Buettner wrote:

> 	* solib.c (reload_shared_libraries): New function.
> 	(_initialize_solib): Add command callbacks for
> 	``set solib-search-path'' and ``set solib-absolute-prefix''.

I've checked this in.

Thanks to Kris for bringing this problem to my attention and for
helping to test the patch.

Kevin