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