This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: unloading shared objects
- To: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- Subject: Re: unloading shared objects
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 13 Mar 2000 12:34:47 -0500
- Cc: gdb at sourceware dot cygnus dot com
- References: <200003102253.XAA04805@reisser.regent.e-technik.tu-muenchen.de>
> > 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.