Moving target specific solib support to generic framework

[Orjan Friberg <orjan dot friberg at axis dot com>]

The thread that originated at
http://sources.redhat.com/ml/gdb-patches/2001-11/msg00096.html resulted
in some private e-mail exchange, reproduced below (with permission). 
The gist is that Kevin Buettner identified that the various target
specific solib support implementations need to be converted to using the
same framework, to eventually have the solib support multi-arched.  I
have volunteered to try and convert one of them (not clear which one
yet).


Kevin Buettner wrote:
> 
> On Dec 4,  6:03pm, Orjan Friberg wrote:
> 
> > Kevin Buettner wrote:
> > >
> > > On Dec 4,  1:58pm, Orjan Friberg wrote:
> > >
> > > > What do you think would be the best development cycle for this?  Convert
> > > > them one at a time (sending patches for each one), or converting them
> > > > all before sending out patches?  I'm thinking something could pop up
> > > > with a later file that would require changes to ones already converted.
> > > > If testing opportunities are scarce, then I might want to put testing
> > > > off until I think I have everything in place, rather than testing as
> > > > early as possible, to minimize the effort put on other people.
> > >
> > > I think it'd be best to convert and test them one at a time.
> >
> > Incremental it is, then.  Kevin, any gut feeling as to which file is a
> > good first candidate for conversion?  coff-solib.c and xcoffsolib.c are
> > certainly the smallest ones, so those might be nice low-hanging fruit to
> > get started on.

[...]

> 
> Smaller doesn't necessarily mean easier.  I think the best candidates
> for early conversion are those files which started out as part of
> (the original monolithic) solib.c.  A file like pa64solib.c might
> be a good one to start with.
> 
> Here's a bit of history as I know it.  I'm not sure which the original
> files were - I'm guessing it was solib.[hc] - but when it came time to
> add shared library support for a native port, one of the existing sets
> of files were copied and then hacked on 'til they worked.  That lead
> to duplication of some fairly generic code that really ought to have
> been kept common.  A little over a year ago, I took solib.c which at
> the time had both SVR4 and SunOS shared library support and split it
> into solib.c which now has the generic portions and solib-svr4.c which
> had the SVR4 and SunOS specific portions.  Earlier this year, I split
> the SunOS support out of solib-svr4.c into its own file.
> 
> For those files which started life as clones of the original solib.[hc],
> we want to take a look at the generic portions and find out if (and how)
> they differ from what's currently in solib.c.  The port specific portions
> need to be massaged to use interface that's been established between
> solib.c and the solib-*.c modules.
> 
> After looking (briefly) at coff-solib.c and xcoffsolib.c, I'm guessing
> that the genesis of these files is quite different.  It will likely take
> more thought to figure out how these files need to be converted.  I should
> think that access to a test machine from the outset would be crucial when
> converting these files.
> 
> Kevin

-- 
Orjan Friberg
Axis Communications AB