On 4/21/10, Artyom Tarasenko <atar4q...@googlemail.com> wrote: > 2010/4/16 Artyom Tarasenko <atar4q...@googlemail.com>: > > > 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) > > > The trick was not to set the breakpoint at 0x70003190. Then the > breakpoint at 0x80 works. > And I think I found a hint: > > http://www.cmpe.boun.edu.tr/courses/cmpe511/fall2004/Ozan Aktan - > Supersparc Architecture.doc > > "One unique feature of the floating-point unit is that dependent > floating-point instructions may be issued in the same instruction > group as the dependent floating-point operation. As an example, the > following instructions can issue in a single clock cycle: > LDD [%i0 + %i1], %f2 > FMULD %f2, %f4, %f6 " > > We also have a dependent instructions > > 0x700030f4: fdivs %f1, %f2, %f3 > 0x700030f8: st %f3, [ %l6 ] > > > which must produce two traps simultaneously: division by zero and > unaligned access. Unaligned access is a higher priority trap, so it > must be processed first. > > In the previous test (which passed) the store produces a data access > exception which has lower priority than division by zero. The test > passes because it is bad.
Currently QEMU executes the IU/FPU instructions synchronously and the IU/FPU traps always arrive in the issue order. What you are describing is called deferred traps in the V8 manual chapter Traps. STDFQ description gives other hints and also Appendix L describes the queue. But I think it would be very hard to model this accurately, you'd have to take into account the instruction execution times, which are then subject to the cache/memory model (in)accuracies.
