This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: solib-search-path not honoured after program start
> 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)