2010/4/15 Artyom Tarasenko <atar4q...@googlemail.com>: > One of LX's tests crashes pretty hard, causing qemu abort. > I've tried to look how does the execution flow works with -d in_asm. > Does the address in the log show the guest's PC register?
It's probably sort of a "timing" issue. Can we check exceptions not just on jumps, but also on floating poit operations which may cause a trap? These traps are supposed to be syncronous. In gdb it looks like this: Breakpoint 1, 0x70002d8c in ?? () (gdb) disas 0x70002d8c,0x70002e3c Dump of assembler code from 0x70002d8c to 0x70002e3c: => 0x70002d8c: fadds %f1, %f2, %f3 0x70002d90: st %f3, [ %l4 ] 0x70002d94: nop 0x70002d98: cmp %g0, %g5 0x70002d9c: bne,a 0x70003a1c 0x70002da0: nop 0x70002da4: mov %g0, %l0 0x70002da8: ld [ %l4 ], %l2 0x70002dac: tst %l2 0x70002db0: bne,a 0x700039ac 0x70002db4: xor %l0, %l2, %l7 0x70002db8: st %fsr, [ %l4 ] 0x70002dbc: ld [ %l4 ], %l2 0x70002dc0: or %l2, 0x10, %l0 0x70002dc4: andcc %l2, 0x10, %l2 0x70002dc8: be,a 0x70003978 0x70002dcc: xor %l0, %l2, %l7 0x70002dd0: nop 0x70002dd4: mov %g3, %i0 0x70002dd8: ret 0x70002ddc: restore 0x70002de0: save %sp, -96, %sp 0x70002de4: btst 2, %g4 0x70002de8: be 0x70002e00 0x70002dec: nop 0x70002df0: sethi %hi(0x8c00), %o0 0x70002df4: or %o0, 0x302, %o0 ! 0x8f02 0x70002df8: call 0x70007440 0x70002dfc: nop 0x70002e00: sethi %hi(0x600000), %l4 0x70002e04: sethi %hi(0xf800000), %l3 0x70002e08: st %l3, [ %l4 ] 0x70002e0c: ld [ %l4 ], %fsr 0x70002e10: mov %g0, %g3 0x70002e14: sethi %hi(0x2c00), %g1 0x70002e18: or %g1, 0x21c, %g1 ! 0x2e1c 0x70002e1c: nop 0x70002e20: sethi %hi(0x7f7ffc00), %l3 0x70002e24: or %l3, 0x3ff, %l3 ! 0x7f7fffff 0x70002e28: st %l3, [ %l4 ] 0x70002e2c: ld [ %l4 ], %f1 0x70002e30: clr [ %l4 ] 0x70002e34: mov 8, %g5 0x70002e38: fadds %f1, %f1, %f3 End of assembler dump. (gdb) break *0x70002d9c Breakpoint 5 at 0x70002d9c (gdb) cont Continuing. Breakpoint 5, 0x70002d9c in ?? () (gdb) cont Continuing. Breakpoint 3, 0x70002e30 in ?? () (gdb) cont Continuing. Breakpoint 2, 0x00000080 in ?? () And then it passes this floating point test, and fails on the next one. With gdb connected the log looks more consequent: IN: 0x70002d8c: fadds %f1, %f2, %f3 -------------- IN: 0x00000080: sethi %hi(0x1c00), %l4 0x00000084: or %l4, 0x324, %l4 ! 0x1f24 0x00000088: jmp %l4 0x0000008c: rd %psr, %l0 -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
