Re: Incompatibilities of userland 5.99.45 and 5.99.48

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

On Thu, 24 Mar 2011 08:28:36 -0700
Matt Thomas <matt%3am-software.com@localhost> wrote:

> I'm going to bet that this is due to crt0 overwriting r2 which was set
> by ld.elf_so.  I think I can fix this with a kludge.

You are right that the crash is r2-related, although the patch didn't
fix it. I had a closer look and saw the DSI-fault is at 0xefea7e4c, while
dereferencing a pointer constructed from r2-28680:

Dump of assembler code for function pthread_mutex_lock:
0xefea7e20 <pthread_mutex_lock+0>:      stwu    r1,-32(r1)
0xefea7e24 <pthread_mutex_lock+4>:      mflr    r0
0xefea7e28 <pthread_mutex_lock+8>:      bcl-    20,4*cr7+so,0xefea7e2c 
<pthread_mutex_lock+12>
0xefea7e2c <pthread_mutex_lock+12>:     stw     r30,24(r1)
0xefea7e30 <pthread_mutex_lock+16>:     mflr    r30
0xefea7e34 <pthread_mutex_lock+20>:     stw     r29,20(r1)
0xefea7e38 <pthread_mutex_lock+24>:     mr      r29,r3
0xefea7e3c <pthread_mutex_lock+28>:     stw     r0,36(r1)
0xefea7e40 <pthread_mutex_lock+32>:     addis   r30,r30,2
0xefea7e44 <pthread_mutex_lock+36>:     addi    r30,r30,-3384
0xefea7e48 <pthread_mutex_lock+40>:     addi    r9,r2,-28680
0xefea7e4c <pthread_mutex_lock+44>:     lwz     r5,4(r9)

In my core dump r9 is 0x1809a68, which is an unmapped region:
(gdb) x 0x1809a68
0x1809a68:      Cannot access memory at address 0x1809a68

The last valid address seems to be 0x1808fff.

The sqlite3 package is quite small and has no dependencies, so I uploaded
it to ftp://ftp.netbsd.org/pub/NetBSD/misc/phx/sqlite3-3.7.4.tgz if you
want to check it on one of your powerpc systems.

-- 
Frank Wille