2010/4/15 Artyom Tarasenko <atar4q...@googlemail.com>: > 2010/4/15 Blue Swirl <blauwir...@gmail.com>: >> On 4/15/10, Artyom Tarasenko <atar4q...@googlemail.com> wrote: >>> 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. >> >> Yes, the bug is that PC and NPC are not saved before executing FPU >> instructions. Please try this patch. > > The patch gets it a couple of tests further: > > FPU SP Invalid CEXC Test > FPU SP Overflow CEXC Test > FPU SP Divide-by-0 CEXC Test > FPU SP Inexact CEXC Test > FPU SP Trap Priority > Test Unassigned mem write access of 4 bytes to > 000000008421f000 from 700030f8 > > FPU SP Trap Priority < Test > ERROR : Unexpected Synchronous Trap Taken, Trap Type = 00000008, > PSR = 414010c4, PC = 70003190, TBR = 00000080 > STATUS : Entering scope loop .... Press <A> key to Abort!qemu: > fatal: Trap 0x03 while interrupts disabled, Error state > pc: 0000217c npc: 00003170 > General Registers: > %g0-7: 00000000 00003170 00000055 00000001 00000002 00000000 00000000 00000000 > > Current Register Window: > %o0-7: 00000000 00000999 00000000 00000000 00000000 00000000 0001fba0 7000971c > %l0-7: 0002fff8 00000000 00000000 00000000 00000000 ffffffff 00000000 00000000 > %i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > Floating Point Registers: > %f00: 000000002.890625 000000025.000000 000000000.000000 000000000.000000 > %f04: 000000002.890625 000000000.000000 000000002.890625 000000000.000000 > %f08: 000000003.390625 000000000.000000 000000002.250000 000000000.000000 > %f12: 000000002.890625 000000000.000000 000000002.312500 000000000.000000 > %f16: 000000002.312500 000000000.000000 000000002.890625 000000000.000000 > %f20: 000000002.718750 000000000.000000 000000002.562500 000000000.000000 > %f24: 000000002.890625 000000000.000000 000000002.968750 000000000.000000 > %f28: 000000002.312500 000000000.000000 000000002.890625 000000000.000000 > psr: 41000000 (icc: ---- SPE: ---) wim: 00000002 > fsr: 0f884002 y: 00000000 > Aborted > > > The code: > > 0x70003174: sethi %hi(0x41c80000), %l3 > 0x70003178: add %l4, 2, %l5 > 0x7000317c: st %l3, [ %l4 ] > 0x70003180: ld [ %l4 ], %f1 > 0x70003184: clr [ %l4 ] > 0x70003188: ld [ %l4 ], %f2 > 0x7000318c: mov 7, %g5 > 0x70003190: fdivs %f1, %f2, %f3
And what is even more strange it looks in qemu.log like if trap is taken, gdb doesn't stop at the 0x080 breakpoint after this operation. Whether I do a stepi or nexti, it just continues up to the crash. Let me know if I can provide more information. Breakpoint 2, 0x00000080 in ?? () (gdb) cont Continuing. Breakpoint 6, 0x70003190 in ?? () (gdb) stepi Remote connection closed (gdb) -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
