Re: unloading shared objects

["Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot 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 ?

>       struct link_map *lmaddr;	/* addr in inferior lm was read from */

E.g. this should be a CORE_ADDR etc...

> !      former in sync with the latter.  Scan both lists, seeing which
> !      shared objects appear where.  There are three cases:
> ! 
> !      - A shared object appears on both lists.  This means that GDB
> !        knows about it already, and it's still loaded in the inferior.
> !        Nothing needs to happen.

This is to simplistic, but improvements might as well be done in another
round of changes (GDB-5.1 ?).

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.


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.

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