Re: unloading shared objects

["Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>]

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

Sorry for the confusion, I noticed this change in semantics a little a
while after I sent the message.
In older versions of GDB this was deemed unacceptable, as it was slowing down
GDB to a crawl on every rerun if you had many shared libraries.

With faster machines and auto-solib-add 0 we might get away with this
approach (although using the old way and a smarter solib algorithm
might have been beneficial for mozilla debugging :-).

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de