Re: [PATCH] solib-svr4.c: Fix set_solib_svr4_fetch_link_map_offsets

[Kevin Buettner <kevinb at cygnus dot com>]

On Sep 21,  9:56pm, Andrew Cagney wrote:

> > As a heads up though, one of the problems is that solib-svr4.c
> > actually contains (ifdef'd) shared library support for both SVR4 and
> > SunOS.  I will be disentangling these mechanisms and will place SunOS
> > shared library support in its own file.  That way we'll be able to do
> > away with the SVR4_SHARED_LIBS macro and we won't accidentally attempt
> > to ever include <link.h> from solib-svr4.c any longer.
> 
> To be honest, I've been very tempted to solve this problem using a very 
> brutal approach: take solib-svr4.c, copy it to solib-aout.c, strip 
> out/in SVR4-SHARED_LIBS code, and then tweek the config files to use either.
> 
> I think this is one of those cases where the desire to re-use the code 
> was taken a little to far - better to get the interfaces right and have 
> a clear separation.  Who cares about a little duplication :-)

Actually, I think this is the right approach.  The duplication of code
is actually desirable because it is then possible to make bug fixes to
the (formerly) common code without having to worry about breaking the
other case.  In other words, over time, the code can safely diverge.

I actually went down this path once - and was nearly finished, but at
the time I thought it might be important for both solib-svr4.c and
solib-aout.c (or perhaps we'll name it solib-sunos.c) to share
current_sos() (now called svr4_current_sos()).  But I no longer think
it's worthwhile to attempt to share current_sos() between these two
shared lib implementations; in fact, I think we may be able to simplify
current_sos() once the split is made.  Looking at the comments, it
appears that there's some SVR4-specific code that the SunOS
implementation doesn't need.  I wouldn't be at all surprised if the
reverse was also true.

Kevin