LIBGCC_SPEC

[Matt Austern]

A comment in gcc.c says "config.h can define LIBGCC_SPEC to override 
how and when libgcc.a is included."

Unfortunately, this comment is no longer true.  A target can indeed 
define LIBGCC_SPEC, but that definition is no longer used.  Instead, 
the LIBGCC_SPEC is munged by a function called init_gcc_specs.  There 
doesn't seem to be any way of turning the munging off (short of 
disabling shared libgcc entirely), which means that targets where the 
munged spec string is inappropriate are just out of luck.

I don't think there's any really clean solution to this problem.  Here 
are the solutions I've thought of:
  1. Do the munging in the preprocessor.  (Surprisingly easy!  I don't 
like macros, but init_gcc_specs is actually clearer when rewritten as a 
macro than as a function.)  Then don't do the munging for targets that 
define LIBGCC_SPEC explicitly.  This will break targets that explicitly 
define nondefault LIBGCC_SPEC and rely on the munging.  Are there any 
such targets?

2. Along the same lines but less drastic: still do the munging in the 
preprocessor and allow a target to define REAL_LIBGCC_SPEC, which will 
get used instead of the munged LIBGCC_SPEC if it exists.

3. Keep the munging as is, but introduce a new macro that allows 
targets to turn it off.  If  
I_MEANT_WHAT_I_SAID_WHEN_I_DEFINED_LIBGCC_SPEC is defined, then we 
don't call init_gcc_specs.

#3 is clearly the simplest choice.  My feeling is that #1 is the 
cleanest.

			--Matt