This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: unloading shared objects
- To: jimb at zwingli dot cygnus dot com (Jim Blandy)
- Subject: Re: unloading shared objects
- From: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- Date: Mon, 13 Mar 2000 18:59:45 MET
- Cc: gdb at sourceware dot cygnus dot com
> > 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