Re: unloading shared objects

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

> > Anyway, I'll finish these when I get back, if nobody else does.  I'd
> > love comments on the changes.
> 
> Looks like the way to go. If at all possible, could you adapt my proposed
> changes to avoid casts to/from CORE_ADDR to your patches ?

Sure thing.

> There are at least two more subcases for this case (which should perhaps
> be mentioned in a FIXME), where _something_ needs to happen:
> 
>       - The DSO might have changed in the meantime, in which case we will
> 	have to reread it. Comparing timestamps between GDB's view
> 	of the DSO and the current DSO will detect this case.
>       - The shared object is now loaded to another address, requiring
> 	relocation of the DSO in GDB's symbol tables etc.
> 	This might happen if another DSO increased in size since the
> 	last run, causing a relocation for the current DSO.
> 	Handling this requires comparison between the current objfile
> 	offsets and the computed offsets for the DSO in the inferior.

The shared object list should be emptied each time the inferior is
started, exactly because the address at which a given shared object is
loaded may vary from run to run.  Within a particular process, shared
objects never change address.  We re-read each shared object's symbols
every time it is loaded.  So I think these are handled trivially.


> And for the next round of changes (GDB-17.0 ?):
> 
> Create a layer between GDB's view of DSOs and the target DSOs.
> This would get rid of duplicated solib.c code in osfsolib.c, irix5-nat.c
> and perhaps the awkward DSO handling in rs6000-nat.c. It might also
> allow us to split solib.c properly into SVR4 and non-SVR4 (SunOS 4.x/BSD)
> components.

Absolutely!  Solaris already has an interface for this, modeled after
the thread_db library, which we may want to emulate.