new way of generating crt[ni].o [patch]

[Zack Weinberg]

Andreas Jaeger wrote:
> >>>>> Zack Weinberg writes:
> 
>  > The new x86 back end wants to generate trampolines to load the PIC
>  > base register all the time (yes, even with -march=i386).  The current
>  > crt[in] generation can't handle this.  So I rewrote it again.  This
>  > version does the split in the object file; it turns out to be much,
>  > much cleaner that way.  On the other hand, it is dependent on more
>  > gnu-binutils-specific features than before.  I'm using binutils
>  > 2.9.5.0.10, but it ought to work with 2.9.1 and later, at least.
> 
> Do I understand your statement correctly that the current gcc cvs
> version doesn't correctly build glibc?  How severe is the problem?

When I tried it, it blew up in the others pass trying to link the
first program against the just-built library.  Error was "undefined
reference to symbol `LPR0'" or something like that; the problem was
that the new ia32 backend does -fPIC like this:

.LPR0:
	movl	(%esp), %ebx
	ret

_init:
	pushl	%ebp
	movl	%esp, %ebp
	pushl	%ebx
	call	.LPR0
	... body of function here ...

The .LPR0 label and its code are lost when we split up the file.

sysdeps/i386/Makefile adds -march=i386 to CFLAGS, which is supposed to
go back to the old style of -fPIC.  It works on a test file, but
doesn't on initfini.c, I don't know why.

zw