[Qemu-devel] Re: sparc32 FPU SP Invalid CEXC Test

[Artyom Tarasenko]

2010/4/21 Blue Swirl <address@hidden>:
> On 4/21/10, Artyom Tarasenko <address@hidden> wrote:
>> 2010/4/16 Artyom Tarasenko <address@hidden>:
>>
>> > 2010/4/15 Artyom Tarasenko <address@hidden>:
>>  >> 2010/4/15 Blue Swirl <address@hidden>:
>>  >>> On 4/15/10, Artyom Tarasenko <address@hidden> wrote:
>>  >>>> 2010/4/15 Artyom Tarasenko <address@hidden>:
>>  >>>>
>>  >>>> > 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.

The question is whether it's worth the effort. Having unaligned access
mixed with floating point operation seems quite artificial to me.

Nevertheless what scares me are window over- and underflow exceptions.

Also, what about v9? There must be also IU deferred traps.

-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/