Re: [RFC] Unconditionally include shared library code

[Mark Kettenis <mark.kettenis@xs4all.nl>]

   Date: Sun, 8 May 2005 09:58:40 -0400
   From: Daniel Jacobowitz <drow@false.org>

   On Sun, May 08, 2005 at 03:15:08PM +0200, Mark Kettenis wrote:
   >    Date: Mon, 2 May 2005 14:51:59 +0200 (CEST)
   >    From: Mark Kettenis <mark.kettenis@xs4all.nl>
   > 
   >    This patch is an attempt to be able to link in the generic shared
   >    library code in solib.c while attempting to keep the shared library
   >    implementations that have not yet been converted to use the generic
   >    code (Windows, coff) working.  It allows me to get rid of
   >    DEPRECATED_TM_FILE in basically every *BSD target.
   > 
   >    I introduce two new files shlib.c, shlib.h.  I need these because
   >    solib.h contains both the prototypes and macro defenitions for the
   >    shared library stuff.  In the long run, I should be able to get rid of
   >    either shlib.[ch] or solib.[ch] again.  I took the opportunity to give
   >    various functions a somewhat more logical name.
   > 
   >    Comments are welcome.  It'd also be great if this could be tested on
   >    Cygwin.
   > 
   > Hmm, no comments yet.  If this is really so uncontroversial, I'm going
   > to check it in next weekend ;-).

   My only comment is that I really don't like having both shlib* and
   solib* (files and interface names).  Could you explain a little more
   why shlib.h is necessary?

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.

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.

My goal is certainly to get rid of either solib.[ch] or shlib.[ch]
once the conversion is done.

Mark