Re: [RFC] Unconditionally include shared library code

[Daniel Jacobowitz <drow@false.org>]

On Sun, May 08, 2005 at 04:21:50PM +0200, Mark Kettenis wrote:
> Me neither.  The usage is very inconsistent within GDB, using both
> shlib and solib in interface dealing with shared libraries.  I'd
> certainly be in favor on us standardizing on one of the two (and I've
> got a slight preference to use shlib).  It would be great if we could
> reach agreement on a consistent naming convention That would make for
> an afwul lot of obvious patches.

I have a slight preference to solib, since that's what the machinery
currently uses.

> But the problem I'm addressing here is solib.h.  It contains both the
> prototypes for the functions in solib.c and the #defines for the hooks
> that make core GDB use those functions.  Since the goal of my patch is
> to get away from using those #defines, I can't simply #include solib.h
> in the core GDB source files, unless I do a massive conversion of all
> targets using solib.h.  That, I think is rather dangerous.  I'd rather
> convert them one-by one, after I've verified that indeed they work
> using the new mechanism.

What bugs me about it is that it's not clear which one is going away.
Would this alternative work for you?  Create a new file, solib-macros.h,
and move the macros from solib.h there.  Have any targets which
currently include solib.h via their TM_FILE include solib-macros.h
instead, which is a nice mechanical update.
 
-- 
Daniel Jacobowitz
CodeSourcery, LLC