busybox segfault in __uClibc_main

Linh Dang linhd at nortel.com
Thu Dec 8 14:25:23 UTC 2005


Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
>>
>> 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.

Hm, ok.

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

So you're the guy I can lobby to change ldso/crt1/__uClibc_main to
work with linux 2.6? :)

>
> 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?

For my local copy of crt1.S, I'd just do:

        if (r7 == 0 || r7 == _start)
                r8 = 0;
        else
                r8 = r7;

















More information about the uClibc mailing list