busybox segfault in __uClibc_main

Joakim Tjernlund joakim.tjernlund at transmode.se
Thu Dec 8 00:25:56 UTC 2005


> -----Original Message-----
> From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Linh Dang
> Sent: den 7 december 2005 20:28
> To: uclibc at uclibc.org
> Subject: Re: busybox segfault in __uClibc_main
> 
> Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
> >>
> >> I think Joakim does have a point (thanx Joakim) and the 
> main problem 
> >> is:
> >>
> >> - with glibc, early code in _start can distinguish whether it was 
> >> called from ldso or from the kernel. this is NOT the case 
> with uClibc 
> >> (atleast with 0.9.28).
> >
> > Yes, I have seen this but glibc runs on sevral OS:es and this never 
> > made any sense to me.
> 
> IMHO, if you cannot make distinction then you SHOULD NOT 
> expect the application to run _dl_fini (I mean ldso's 
> _dl_fini not _init stuffs in the application). Right now 
> _dl_fini is run by the application (uClibc actually)!

I know, it can't be any other way because once you leave ld.so there
is no way back.

> 
> >
> >>
> >> - ppc uClibc assumes that all registers are cleared 
> (except for r1) 
> >> once it reach _start. I'm not sure if it's the case with 
> >> CONFIG_PREEMPT kernel.  it passed the value of r7 as rtld_fini 
> >> parameter to __uClibc_main() assuming that r7 will be 0 if 
> it was a 
> >> staticly linked prog.
> >
> > uClibc assumes that r7 is cleared and r1 points to argc on stack.
> > Last time I looked in the kernel it seemed this was the case, but I 
> > not sure.  Maybe Linux behaves diffrently for static vs. 
> dynamic apps?  
> > I would really like to see a spec for startup behaviour for 
> linux, I 
> > never found one.
> 
> >From the application it's different because in one case it's invoked
> by ldso and the other case by the kernel. From the kernel 
> pov, it would either jump into the entry point of the 
> application or the entry point of ldso.

Tell me something I don't know, I wrote much of the current ld.so/crt1/__uClibc_main
interface code. 

> 
> >
> > if r1 really pointed to a null word, then the rest of crt is wrong
> 
> My mistake I thought uClibc's ldso would be SysV ABI 
> compliant and it's NOT.

That's because Linux isn't SysV ABI compliant either . The best spec I can find is
http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-PPC32/LSB-Core-PPC32.html#PROCESSINITIALIZATION

"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."

> 
> 
> > too and your patch would not work since argc, argv etc. are off by 
> > one.  Maybe you should try without CONFIG_PREEMPT?
> >
> > Also try a simple static hello world app to make trouble shooting 
> > easier.
> 
> I think I explained it below: rtld_fini point to the wrong 
> thing and it would make ANY static app segfault.

Still think you got a kernel bug




More information about the uClibc mailing list