busybox segfault in __uClibc_main

[Joakim Tjernlund]

> > Tell me something I don't know, I wrote much of the current 
> > ld.so/crt1/__uClibc_main interface code.
> 
> So you're the guy I can lobby to change 
> ldso/crt1/__uClibc_main to work with linux 2.6? :)

Sure, just be patient as I don't have much time on my hands at the moment.

> 
> >
> > Still think you got a kernel bug
> 
> Well, from your point of view it may be, but I'm not 
> qualified to go in LKML and argue on behalf of uClibc.
> 
> The problem is the MISMATCH between kernel 2.6.x (at least 
> from 2.6.10 and up) and uClibc. uClibc expect r7 to be 0 in 
> _start() of a staticly linked app.
> 
> I dumped the registers out:
> 
> r1 = 0x7fe8be30 (stack)
> r2 = 0
> r3 = 0
> r4 = 0
> r5 = 0
> r6 = 0
> r7 = 0x100000b8 (_start)
> r8 = 0xd032     (MSR)
> 
> 
> So I went looking into the kernel 2.6 code:
> 
>   ret_from_syscall:
>         ....
> 	lwz	r1,GPR1(r1)
> 	mtspr	SPRN_SRR0,r7
> 	mtspr	SPRN_SRR1,r8
> 	SYNC
> 	RFI
> 
> Voila! r7 contained the PC and r8 contained the MSR of the 
> new task/process (the new process starts upon the return of 
> the exec() syscall).
> 
> So Joakim, you'll do the talking in LKML?

I sent a mail to linuxppc-dev(you got a cc) but I used my other email address(bugger)

> 
> For my local copy of crt1.S, I'd just do:
> 
>         if (r7 == 0 || r7 == _start)
>                 r8 = 0;
>         else
>                 r8 = r7;

Would you mind changing that to:
if(r7 == _start)
   r7 = 0;
and send a patch(add a comment too)? I suspect that it will take time to change the kernel, if at all.

Have you tested static apps with glibc too?
 
 Jocke