Linux process ABI broken in 2.6?

[Joakim Tjernlund]

> On Fri, 2005-12-09 at 00:07 +0100, Tjernlund wrote:
> > Seems like ppc32 kernel pass the application entry point address
> > in r7 and MSR in r8 when starting the application. The source might
be
> > ret_from_syscall, in entry.S: 
> > 	...
> > 	lwz	r7,_NIP(r1)
> >  	lwz	r8,_MSR(r1)
> >  	FIX_SRR1(r8, r0)
> >  	lwz	r2,GPR2(r1)
> > 	lwz	r1,GPR1(r1)
> > 	mtspr	SPRN_SRR0,r7
> > 	mtspr	SPRN_SRR1,r8
> > 	SYNC
> > 	RFI
> > I am not convinced this is the source, but a non zero r7
> > breaks static apps in uClibc.
> > 
> > Is this on purpose and why?
> > 
> > Secion 8.4.1 in
> >
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-PPC32/LSB-Core-PPC3
2.html#PROCESSINITIALIZATION
> > 
> > says:
> > "Contrary to what is stated in the Registers part of chapter 3 of
the System V Application Binary Interface PowerPC Processor
> > Supplement there are no values set in registers r3, r4, r5, r6 and
r7. Instead the values specified to appear in all of those
> > registers except r7 are placed on the stack. The value to be placed
into register r7, the termination function pointer is not passed
> > to the process."
> > 
> > How do one not pass a termination function in r7 other than setting
> > r7 to zero?
>
> Just ignore those registers on entry. The semantics of a syscall are
to
> clobber all volatile registers and there is no point doing anything
> else.
>
> Ben.

[Sorry to break the thread, but I mailed from the wrong account which I
can't reach ATM]

Sure, but this syscall is a bit special as it has to prepare the runtime
env. for the new process.
Not having any defined value for register at process startup feels ..

An undefined r7 register makes it hard to differ between dynamic and
static apps in crt1.
I now understand why glibc has its own non standard __libc_start
function and I really don't
want that in uClibc. Is it too much trouble to define r7 to always have
a zero
value at process startup?

As far as I can tell 2.4 has all unused registers zeroed.

 Jocke