Re: unloading shared objects

[Jim Kingdon <kingdon at redhat dot com>]

> At present, GDB assumes that we know the shared object's load address
> when we read the symbols.  Perhaps this is a poor assumption, but it
> is pretty fundamental to the current symbol table structure.  I'm not
> going to fix that as part of this dlclose change.

Well, objfile_relocate was written to address this.  But I agree,
trying to fix this as part of the dlclose fix could be biting off more
than is warranted.

> - free_objfile calls CLEAR_SOLIB, which isn't what we want, I think.

Ouch.  That looks really bad.  I suspect the CLEAR_SOLIB call can and
should be moved up to symbol_file_command (note the call to
SOLIB_RESTART - currently vestigial at least on Linux - which relates
to the issue of whether to nuke all the shared library symbols on
every run of the program).

> - Selecting a core file and attaching to a process both add the shared
> libraries' sections to the target_ops structure.  When we unload a
> shared library, we close the BFD those sections refer to.  We
> need to remove those sections from the target_ops structure.

You noticed that one too, eh? ;-).

> - Should solib.c be maintaining its own list of shared objects at all,
>   or should it always retrieve the full link map from the inferior,
>   and use the objfile list itself as our record of what we know about?

Haven't looked at the code long enough to have a really good feel for
this, but I think you are probably right.  That your changes to nuke
find_solib separate out the inferior access code enough to make the
above practical.

Anyway, thanks for writing this code and let me know if there is
anything else I can do (at the moment, various ideas and encouragement
seem like a better way for me to help than writing code - not only was
my solib.c code somewhat buggy/unpopular, but I didn't really enjoy
writing it either :-)).