PATCH RFC: Remove fork from collect2

[Ian Lance Taylor]

Andrew Pinski <apinski@apple.com> writes:

> On Mar 19, 2004, at 1:30 PM, Caroline Tice wrote:
> >
> > After some investigation, I found that the symbols restFP and saveFP
> > are  coming into libiberty.a from
> > pex-unix.o.  By replacing libiberty/pex-unix.c with an older version
> > of pex-unix.c (from before you applied
> > your patch), the problem goes away.  I haven't had the chance to
> > investigate this further yet, but I
> > wanted to mention it.
> >
> > ctice% nm -o ../libiberty/libiberty.a | grep restFP
> > ../libiberty/libiberty.a:pex-unix.o:         U restFP
> > ctice% nm -o ../libiberty/libiberty.a | grep saveFP
> > ../libiberty/libiberty.a:pex-unix.o:         U saveFP
> > ctice% nm -o ../libiberty/pex-unix.o | grep saveFP
> > ../libiberty/pex-unix.o:         U saveFP
> > ctice% nm -o ../libiberty/pex-unix.o | grep restFP
> > ../libiberty/pex-unix.o:         U restFP
> 
> Actually this is an issue with Apple versus FSF libgcc and the name of
> the
> function which saves/restores the FP so to resolve this issue either
> the FSF's gcc has to have the functions in Darwin's libgcc or have
> libiberty
> be built like the rest of the compiler, in each stage.

Interesting.

First I have to ask why pex-unix.c is bringing in restFP and saveFP.
The only significant change I made was to replace fork with vfork.  I
can imagine that vfork might be an inline function on Darwin, but it's
hard for me to see why it would be inlined when using the Apple
version of gcc but not when using the FSF gcc.

Or is the problem that the Apple gcc recognizes vfork specially, and
open codes it, calling saveFP and restFP?  Is there some command line
option we could use to disable that, to generate code which could be
linked by either Apple gcc or FSF gcc?  Note in particular that there
is no floating point code between the vfork and the exec, so there is
no actual need to save the floating point state.  Also note that
generating calls to functions which are in the user's namespace would
appear to be a bad thing.  However, I don't know any of the details.

I can see the following possible solutions:

1) Change the pex-unix.c code to use a different function on a Darwin
   host, either just calling fork, or calling some other variant if
   there is one.

2) Write pex-darwin.c, and use that instead of pex-unix.c.

3) Add restFP and saveFP to FSF gcc.  Overall consistency would appear
   to be a good thing.

4) Make the libiberty directory bootstrap like the gcc directory.
   Probably a bit of a pain to implement.  On the other hand, it might
   provide an infinitesimal speedup on some systems, as the new
   version of gcc can do full optimization on the libiberty routines
   that it uses.

Ian