Re: libtarget.a?

[Mark Mitchell <mark at codesourcery dot com>]

> 	BUT, this is relevant to ppc32.  Again, the System V Application
> Binary Interface PowerPC Processor Supplement (ppc32) EXPLICITLY states:
> "The retister saving and retoring functions described in this section use
> non-standard calling conventions which require them to be statically
> linked into any executable or shared object modules in which they are
> used."  The FPR functions may happen to be safe, but the ABI does not
> guarantee that.

My two cents:

1. On GNU/Linux systems, using libc seems appropriate, as we just hashed
   out for PA.  It seems like the GNU linker magic allows you to make
   libc really contain a static archive, and since everything's getting
   linked against libc, you win automatically.

2. On other systems, crt*.o still seems like a fine place to put these
   things to me.  Alan's comment that you then end up linking in the
   routines when you don't need them doesn't worry me -- you already
   end up with static constructor stuff that you don't need.  Besides,
   we're talking about tiny routines -- probably only a few K of code
   space.  And if you don't have floating point at all on your target,
   you can turn this stuff off.  Or, you can have a --no-fp option
   that links in a different crt*.o object that doesn't have the funky
   routines.

3. On some other systems, GCC may be able to use the routines provided
   by the vendor wherever they provided them.  In that case, the target
   can just indicate that we should link against this library.

So, I do not see the need for introducing yet more complexity into are
already incredibly tangled build process.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com