On Sat, 13 Nov 2010 11:43:23 +0800 terry gliumailenator@gmail.com wrote:
and the following is part of malloc after disassembled, you can find the detailed content of malloc in the attachment malloc.dis file(I'm not sure which part could be useful,so I attached whole malloc).
61 33f8fb84: 9a000004 bls 33f8fb9c <malloc+0xf8> 62 33f8fb88: e59f352c ldr r3, [pc, #1324] ; 33f900bc <malloc +0x618> 63 33f8fb8c: e1520003 cmp r2, r3 64 33f8fb90: 91a0392a lsrls r3, sl, #18 65 33f8fb94: 83a0207e movhi r2, #126 ; 0x7e 66 33f8fb98: 9283207c addls r2, r3, #124 ; 0x7c 67 33f8fb9c: e59f3514 ldr r3, [pc, #1300] ; 33f900b8 <malloc +0x614> 68 33f8fba0: e0834182 add r4, r3, r2, lsl #3 69 33f8fba4: e594000c ldr r0, [r4, #12] 70 33f8fba8: ea000012 b 33f8fbf8 <malloc+0x154> 71 33f8fbac: e5903004 ldr r3, [r0, #4] 72 33f8fbb0: e3c33003 bic r3, r3, #3 ; 0x3 //it seems that exception occurs here 73 33f8fbb4: e06a1003 rsb r1, sl, r3
This is the instruction that it faulted on -- but it's not a memory access instruction. Could it be an asynchronous data abort (more like a machine check)? It's been a while since I've done ARM stuff.
/me googles "ARM exceptions"
Hmm, data aborts record PC+8 rather than PC? Who comes up with this stuff? :-P
Could you look up the line number information for 0x33f8fbac?
From the full-function disasm, I'd expect ip to equal r0 at this point -- but they don't in the dump.
-scott