Re: DSI trap in init

[Frank Wille <frank%phoenix.owl.de@localhost>]

KIYOHARA Takashi wrote:

>> Since a couple of days the init process dies on several (all?) PowerPC
>> ports. This message appears infinitely when launching /sbin/init:
>> 
>> Process (pid 1) got sig 11
>> trap: pid 1.1 (init): user read DSI trap @ 0xffffffff by 0xefe940fc
>> (DSISR 0x40000000, err=14)
>
>> I tested with a G3 under ofppc and with a MPC8241 under sandpoint.
>> Generic kernel and userland are from yesterday.
>
> Me too.
> My prep machine from 9 Feb.
> [...]

Today I tried the latest snapshot from 201102192100Z, which still has the
same problem.


So for a test I copied bin/sleep from base.tgz to my working system with
5.99.45 kernel and 5.99.43 userland. It immediate segfaults when running
it, very early during _rtld_setup():

---8<---
Core was generated by `sleep'.
Program terminated with signal 11, Segmentation fault.
#0  0x4e800420 in ?? ()
(gdb) bt
#0  0x4e800420 in ?? ()
#1  0x0180076c in _rtld_setup ()
#2  0x01800858 in _start ()
---8<---

The 0x4e800420 is a BCTR instruction, which is suspicious. Further
analyzation shows that the crash happens during the atexit() call in
_rtld_setup(). Looks like a PLT stub which tries to fetch the real address
of atexit in the shared object:

---8<---
0x01800e40 <call___do_global_ctors_aux+100>:    lis     r11,385
0x01800e44 <call___do_global_ctors_aux+104>:    lwz     r11,4560(r11)
0x01800e48 <call___do_global_ctors_aux+108>:    mtctr   r11
0x01800e4c <call___do_global_ctors_aux+112>:    bctr
---8<---

But the location where it expects the address actually contains code:

---8<---
(gdb) x 0x1800e40
0x1800e40 <call___do_global_ctors_aux+100>:     0x3d600181
(gdb) x 0x1800e44
0x1800e44 <call___do_global_ctors_aux+104>:     0x816b11d0
(gdb) disassemble 0x18111d0
Dump of assembler code for function atexit@plt:
0x018111d0 <atexit@plt+0>:      bctr
End of assembler dump.
---8<---

objdump shows the same part of the program as:

 1800764:       7f a3 eb 78     mr      r3,r29
 1800768:       48 00 06 d9     bl      1800e40 <atexit@plt>
...
01800e40 <atexit@plt>:
 1800e40:       3d 60 01 81     lis     r11,385
 1800e44:       81 6b 11 d0     lwz     r11,4560(r11)
 1800e48:       7d 69 03 a6     mtctr   r11
 1800e4c:       4e 80 04 20     bctr

Strange that atexit@plt is now at 0x1800e40, while it is 0x18111d0 in the
core dump.

There is something very wrong with PLT and the ld.so...

-- 
Frank Wille