On Sat, 13 Nov 2010 11:43:23 +0800 terry <gliumailena...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
