This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: unloading shared objects
> 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 :-)).