Re: [patch] Provide a target macro that allows unmodified LIBGCC_SPEC

[Geoff Keating <geoffk at geoffk dot org>]

Matt Austern <austern@apple.com> writes:

> As I pointed out in an earlier message: at present, if
> ENABLE_SHARED_LIBGCC is defined, the compiler unconditionally mungs
> whatever LIBGCC_SPEC the target provides.  I find this very
> unfortunate: a target that defines a nondefault LIBGCC_SPEC probably
> has a good reason for it, and the complicated modifications we get
> init_gcc_specs and init_spec are likely to conflict with special
> target needs.  (Conjecture: this is already causing bugs, but nobody
> has noticed because the bugs only come up in unusual combinations of
> flags.)
> 
> This is somewhere between a workaround and a fix.  I don't know what
> LIBGCC_SPEC should be like on every target out there, and I don't know
> which targets should and shouldn't use the init_gcc_specs munging.  So
> instead all I'm doing is providing a mechanism that allows a target to
> provide a version of LIBGCC_SPEC.  I admit that this isn't a very
> clean solution, but I think it's the best we can do given where we are
> now.
> 
> Testing: bootstrapped on OS X, verified that this didn't interfere
> with the default libgcc spec.
> 
> OK to commit to mainline?

This is OK (except it needs a ChangeLog).

> Index: gcc/gcc.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
> retrieving revision 1.405
> diff -p -r1.405 gcc.c
> *** gcc/gcc.c	24 Jan 2004 10:09:48 -0000	1.405
> --- gcc/gcc.c	15 Feb 2004 17:19:34 -0000
> *************** static int execute (void);
> *** 345,351 ****
>    static void alloc_args (void);
>    static void clear_args (void);
>    static void fatal_error (int);
> ! #ifdef ENABLE_SHARED_LIBGCC
>    static void init_gcc_specs (struct obstack *, const char *, const
> char *,
>    			    const char *);
>    #endif
> --- 345,351 ----
>    static void alloc_args (void);
>    static void clear_args (void);
>    static void fatal_error (int);
> ! #if defined(ENABLE_SHARED_LIBGCC) && !defined(REAL_LIBGCC_SPEC)
>    static void init_gcc_specs (struct obstack *, const char *, const
> char *,
>    			    const char *);
>    #endif
> *************** proper position among the other output f
> *** 598,604 ****
>    /* config.h can define LIBGCC_SPEC to override how and when
> libgcc.a is
>       included.  */
>    #ifndef LIBGCC_SPEC
> ! #if defined(LINK_LIBGCC_SPECIAL) || defined(LINK_LIBGCC_SPECIAL_1)
>    /* Have gcc do the search for libgcc.a.  */
>    #define LIBGCC_SPEC "libgcc.a%s"
>    #else
> --- 598,606 ----
>    /* config.h can define LIBGCC_SPEC to override how and when
> libgcc.a is
>       included.  */
>    #ifndef LIBGCC_SPEC
> ! #if defined(REAL_LIBGCC_SPEC)
> ! #define LIBGCC_SPEC REAL_LIBGCC_SPEC
> ! #elif defined(LINK_LIBGCC_SPECIAL) || defined(LINK_LIBGCC_SPECIAL_1)
>    /* Have gcc do the search for libgcc.a.  */
>    #define LIBGCC_SPEC "libgcc.a%s"
>    #else
> *************** static int processing_spec_function;
> *** 1522,1528 ****
>    /* Add appropriate libgcc specs to OBSTACK, taking into account
>       various permutations of -shared-libgcc, -shared, and such.  */
> 
> ! #ifdef ENABLE_SHARED_LIBGCC
>    static void
>    init_gcc_specs (struct obstack *obstack, const char *shared_name,
>    		const char *static_name, const char *eh_name)
> --- 1524,1530 ----
>    /* Add appropriate libgcc specs to OBSTACK, taking into account
>       various permutations of -shared-libgcc, -shared, and such.  */
> 
> ! #if defined(ENABLE_SHARED_LIBGCC) && !defined(REAL_LIBGCC_SPEC)
>    static void
>    init_gcc_specs (struct obstack *obstack, const char *shared_name,
>    		const char *static_name, const char *eh_name)
> *************** init_spec (void)
> *** 1589,1595 ****
>          next = sl;
>        }
> 
> ! #ifdef ENABLE_SHARED_LIBGCC
>      /* ??? If neither -shared-libgcc nor --static-libgcc was
>         seen, then we should be making an educated guess.  Some proposed
>         heuristics for ELF include:
> --- 1591,1597 ----
>          next = sl;
>        }
> 
> ! #if defined(ENABLE_SHARED_LIBGCC) && !defined(REAL_LIBGCC_SPEC)
>      /* ??? If neither -shared-libgcc nor --static-libgcc was
>         seen, then we should be making an educated guess.  Some proposed
>         heuristics for ELF include:
> Index: gcc/doc/tm.texi
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/doc/tm.texi,v
> retrieving revision 1.297
> diff -p -r1.297 tm.texi
> *** gcc/doc/tm.texi	8 Feb 2004 23:08:48 -0000	1.297
> --- gcc/doc/tm.texi	15 Feb 2004 17:20:11 -0000
> *************** If this macro is not defined, the GCC dr
> *** 293,298 ****
> --- 293,310 ----
>    passes the string @option{-lgcc} to the linker.
>    @end defmac
> 
> + @defmac REAL_LIBGCC_SPEC
> + By default, if @code{ENABLE_SHARED_LIBGCC} is defined, the
> + @code{LIBGCC_SPEC} is not directly used by the driver program but is
> + instead modified to refer to different versions of @file{libgcc.a}
> + depending on the values of the command line flags @code{-static},
> + @code{-shared}, @code{-static-libgcc}, and @code{-shared-libgcc}.  On
> + targets where these modifications are inappropriate, define
> + @code{REAL_LIBGCC_SPEC} instead.  @code{REAL_LIBGCC_SPEC} tells the
> + driver how to place a reference to @file{libgcc} on the link command
> + line, but, unlike @code{LIBGCC_SPEC}, it is used unmodified.
> + @end defmac
> +
>    @defmac STARTFILE_SPEC
>    Another C string constant used much like @code{LINK_SPEC}.  The
>    difference between the two is that @code{STARTFILE_SPEC} is used at
> 
> 

-- 
- Geoffrey Keating <geoffk@geoffk.org>