busybox segfault in __uClibc_main

[Linh Dang]

Rob Landley <rob at landley.net> wrote:

> On Tuesday 06 December 2005 11:32, Joakim Tjernlund wrote:
>> Maybe(need to check my assembler skills I guess), I read it as:
>> if(r4)
>> r8 = 0;
>>
>> r4 holds argc and I don't get how it can be anything but non zero
>> so this should always clear r8 and you don't want that for dynamic
>> apps.
>
> Modifying argc and argv the way the current stable busybox does
> sucketh mightily.  (It might be a bug that uclibc sets things up so
> that doing this segfaults, but it's still a very dodgy thing busybox
> is doing.)
>
> Does moving to -pre1 fix it for you?  In about three weeks, this
> should be the new busybox -stable and it would be nice if we work on
> uClibc 0.9.28 on PPC with the 2.6.14 kernel...
>
>> Jocke
>
> Rob

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

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

- so in __uClibc_main(), its rtld_fini is _dl_fini in the case of a
  dynamicly linked prog, garbage (somehow it point to _start) in a
  staticly linked prog. That why any program would segfault int exit()
  when it try to call __rtld_fini.

- r7 is somehow cleared when a program is ptraced, that why I couldn't
  debug this problem with gdb nor it would crash under strace.


Regards

--
Linh Dang