Re: PPC startup code

[Roland McGrath <roland at redhat dot com>]

> I just compiled up and tested glibc with the following patch to
> start.S and libc-start.c, using the generic libc-start.c with a hack
> to do the __aux_cache_init thing (inside #ifdef __powerpc__).  It all
> works just fine.  With this patch we do the detection of static
> binaries inside start.S.  We end up doing the same computations as
> before, though, so it shouldn't break anything.  

> Some of the work that the PPC dl-start.S does is now redundant and could
> be eliminated.

That has to be done because the ABI says that those values are in those
registers when dynamic linker jumps to the user the entry point (start.S).
There is nothing in the ABI that prevents the dynamic linker from having
the things layed out on the stack differently if it points the registers in
the right places.  In fact, our ld.so does that when you run it directly
(i.e. "ld.so program arg1 arg2") as we use for testing and in the glibc build.
(It passes a decremented argc and an incremented argv.)

> Roland, is this the sort of thing you wanted?  I assume there is a
> cleaner way to do the __aux_cache_init thing in libc-start.c.

This is roughly what I had in mind.  The __aux_cache_init function should
be defined in powerpc/elf/libc-start.c, which should define a macro like
#define AUX_VECTOR_INIT __aux_cache_init and do 
#include <sysdeps/generic/libc-start.c>, which should have the AUX_VECTOR_INIT
call inserted in the right spot in #ifdef AUX_VECTOR_INIT.

If you change the __libc_start_main calling sequence, then you have to use
a new symbol version and support the old calling sequence.  Looking around
in the sources for SHLIB_COMPAT will show you how this is done, and I don't
mind doing that part myself.  

I think changing the __libc_start_main calling sequence now so as not to be
gratuitously goofy and unlike every other platform is a nice cleanup.  But
it does mean that powerpc users will have to be especially sure they have
the crt1.o that matches the libc they have installed at link time.  It's
always the case that these come together as part of the libc install and
users have to link against a crt1.o and libc.so from the same install.  
But the crt1.o ABI almost never changes in practice so one could have
flubbed this and not been screwed in the past.

Symbol versioning will make the ABI change perfectly safe and backward
compatible with existing binaries.  But if the potential of new development
mishaps is too much trouble, then there is no great harm in leaving the
goofy calling sequence for __libc_start_main.  What matters most is to
avoid the unnecessary source duplication.  We can do that by modifying
generic/libc-start.c (in addition to the AUX_VECTOR_INIT change) with a
little bit of #ifdef hair to define a static function instead of
__libc_start_main so that you can #include it and define the wrapper entry
point.

In fact, I don't mind doing all this cleanup in libc-start.c myself.
Someone just has to decide about whether start.S and the calling sequence
ought to change or stay the same.  I vote for changing it to match every
other platform.  But I don't speak for powerpc users.