[Qemu-devel] sparc32 FPU SP Invalid CEXC Test

[Qemu-devel] sparc32 FPU SP Invalid CEXC Test

[Artyom Tarasenko]

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?
If so it looks strange:

0x70002d8c:  fadds  %f1, %f2, %f3
0x70002d90:  st  %f3, [ %l4 ]
0x70002d94:  nop
0x70002d98:  cmp  %g0, %g5
0x70002d9c:  bne,a   0x70003a1c

--------------
IN:
0x00000080:  sethi  %hi(0x1c00), %l4
0x00000084:  or  %l4, 0x324, %l4        ! 0x1f24
0x00000088:  jmp  %l4
0x0000008c:  rd  %psr, %l0

--------------
IN:
0x00001f24:  rd  %tbr, %l3
0x00001f28:  srl  %l3, 4, %l3
0x00001f2c:  and  %l3, 0xff, %l3
0x00001f30:  cmp  %l3, %g5
0x00001f34:  bne,a   0x2044

--------------
IN:
0x00001f3c:  sethi  %hi(0x600000), %l4
0x00001f40:  or  %l4, 0x100, %l4        ! 0x600100
0x00001f44:  add  %l4, 8, %l5
0x00001f48:  sethi  %hi(0x2000), %l6
0x00001f4c:  st  %fsr, [ %l4 ]
0x00001f50:  ld  [ %l4 ], %l7
0x00001f54:  andcc  %l7, %l6, %l7
0x00001f58:  bne  0x1f68
0x00001f5c:  nop

--------------
IN:
0x00001f60:  b  0x1f74
0x00001f64:  nop

--------------
IN:
0x00001f74:  mov  %g0, %g5
0x00001f78:  mov  %l0, %psr

--------------
IN:
0x00001f7c:  nop
0x00001f80:  nop
0x00001f84:  nop
0x00001f88:  jmp  %l2
0x00001f8c:  rett  %l2 + 4

--------------
########### Here: why does it return to 0x70002d84, not to 0x70002d94 ?

IN:
0x70002d84:  clr  [ %l4 ]
0x70002d88:  mov  8, %g5
0x70002d8c:  fadds  %f1, %f2, %f3
0x70002d90:  st  %f3, [ %l4 ]
0x70002d94:  nop
0x70002d98:  cmp  %g0, %g5
0x70002d9c:  bne,a   0x70003a1c

--------------
######## Here: why does it jump to 0x70002d88?
IN:
0x70002d88:  mov  8, %g5
0x70002d8c:  fadds  %f1, %f2, %f3
0x70002d90:  st  %f3, [ %l4 ]
0x70002d94:  nop
0x70002d98:  cmp  %g0, %g5
0x70002d9c:  bne,a   0x70003a1c

--------------
IN:
0x70002d8c:  fadds  %f1, %f2, %f3
0x70002d90:  st  %f3, [ %l4 ]
0x70002d94:  nop
0x70002d98:  cmp  %g0, %g5
0x70002d9c:  bne,a   0x70003a1c

>From the OBP log messages it looks like the trap 8 is signalled at
least one time more than expected.
Multiple execution of "0x70002d8c:  fadds  %f1, %f2, %f3" would have explain it:

     ERROR : Unexpected Synchronous Trap Taken, Trap Type = 00000008,
PSR = 414010c4, PC = 70002d8c, TBR = 00000080
     STATUS : Entering scope loop .... Press <A> key to Abort!qemu:
fatal: Trap 0x03 while interrupts disabled, Error state
pc: 0000217c  npc: 00002d68
General Registers:
%g0-7: 00000000 00002d68 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              inf             -inf 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: 0f880010 y: 00000000
Aborted


-- 
Regards,
Artyom Tarasenko

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

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

[Artyom Tarasenko]

2010/4/15 Artyom Tarasenko <atar4qemu@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/

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

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On 4/15/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
> 2010/4/15 Artyom Tarasenko <atar4qemu@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.

[-- Attachment #2: 0001-Sparc-fix-PC-NPC-during-FPU-traps.patch --]
[-- Type: text/x-diff, Size: 1350 bytes --]

From 6c7d08b06214337f2b95d865b33c7ca188899fa4 Mon Sep 17 00:00:00 2001
From: Blue Swirl <blauwirbel@gmail.com>
Date: Thu, 15 Apr 2010 17:14:28 +0000
Subject: [PATCH] Sparc: fix PC/NPC during FPU traps

All FPU instructions can trap, so save PC/NPC state before
executing them.

Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
---
 target-sparc/translate.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/target-sparc/translate.c b/target-sparc/translate.c
index 2c07385..addb1e1 100644
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -2155,6 +2155,7 @@ static void disas_sparc_insn(DisasContext * dc)
                 rs1 = GET_FIELD(insn, 13, 17);
                 rs2 = GET_FIELD(insn, 27, 31);
                 xop = GET_FIELD(insn, 18, 26);
+                save_state(dc, cpu_cond);
                 switch (xop) {
                 case 0x1: /* fmovs */
                     tcg_gen_mov_i32(cpu_fpr[rd], cpu_fpr[rs2]);
@@ -2468,6 +2469,7 @@ static void disas_sparc_insn(DisasContext * dc)
                 rs1 = GET_FIELD(insn, 13, 17);
                 rs2 = GET_FIELD(insn, 27, 31);
                 xop = GET_FIELD(insn, 18, 26);
+                save_state(dc, cpu_cond);
 #ifdef TARGET_SPARC64
                 if ((xop & 0x11f) == 0x005) { // V9 fmovsr
                     int l1;
-- 
1.5.6.5

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

[Artyom Tarasenko]

2010/4/15 Blue Swirl <blauwirbel@gmail.com>:
> On 4/15/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
>> 2010/4/15 Artyom Tarasenko <atar4qemu@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
   0x70003194:  st  %f3, [ %l5 ]
   0x70003198:  nop

Is it a test for MMU trap inside of  fpu trap?
qemu.log:

0x70003190:  fdivs  %f1, %f2, %f3
--------------
IN:
0x00000080:  sethi  %hi(0x1c00), %l4
0x00000084:  or  %l4, 0x324, %l4        ! 0x1f24
0x00000088:  jmp  %l4
0x0000008c:  rd  %psr, %l0
--------------
IN:
0x00001f24:  rd  %tbr, %l3
0x00001f28:  srl  %l3, 4, %l3
0x00001f2c:  and  %l3, 0xff, %l3
0x00001f30:  cmp  %l3, %g5
0x00001f34:  bne,a   0x2044
--------------
IN:
0x00001f38:  nop
--------------
IN:
0x00002044:  sethi  %hi(0x10001000), %l5
0x00002048:  or  %l5, 4, %l5    ! 0x10001004
0x0000204c:  lda  [ %l5 ] #ASI_M_BYPASS, %l7
0x00002050:  sethi  %hi(0x10001000), %l4
0x00002054:  lda  [ %l4 ] #ASI_M_BYPASS, %l6
0x00002058:  sethi  %hi(0x80000000), %l5
0x0000205c:  btst  %l6, %l5
0x00002060:  be  0x20bc
0x00002064:  nop

--------------
IN:
0x000020bc:  mov  0x400, %l5    ! 0x400
0x000020c0:  lda  [ %l5 ] #ASI_M_MMUREGS, %l7
0x000020c4:  nop
0x000020c8:  mov  0x300, %l4    ! 0x300
0x000020cc:  lda  [ %l4 ] #ASI_M_MMUREGS, %l6
0x000020d0:  sethi  %hi(0x7c00), %l5
0x000020d4:  or  %l5, 0x1c, %l5 ! 0x7c1c
0x000020d8:  btst  %l6, %l5
0x000020dc:  be  0x2134
0x000020e0:  nop

--------------
IN:
0x00002134:  sethi  %hi(0x8400), %i0


The "Trap Priority >" test (which passed) also produced some
interesting qemu.log:


0x700030f4:  fdivs  %f1, %f2, %f3
0x700030f8:  st  %f3, [ %l6 ]
0x700030fc:  nop
0x70003100:  cmp  %g0, %g5
0x70003104:  bne,a   0x70003a1c

--------------
IN:
0x00000080:  sethi  %hi(0x1c00), %l4

############## Here, double trap?!
--------------
IN:
0x00000080:  sethi  %hi(0x1c00), %l4

--------------
IN:
0x00000084:  or  %l4, 0x324, %l4        ! 0x1f24
0x00000088:  jmp  %l4
0x0000008c:  rd  %psr, %l0

--------------
IN:
0x00001f24:  rd  %tbr, %l3
0x00001f28:  srl  %l3, 4, %l3
0x00001f2c:  and  %l3, 0xff, %l3
0x00001f30:  cmp  %l3, %g5



-- 
Regards,
Artyom Tarasenko

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

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

[Artyom Tarasenko]

2010/4/15 Artyom Tarasenko <atar4qemu@googlemail.com>:
> 2010/4/15 Blue Swirl <blauwirbel@gmail.com>:
>> On 4/15/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
>>> 2010/4/15 Artyom Tarasenko <atar4qemu@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/

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

[Artyom Tarasenko]

2010/4/16 Artyom Tarasenko <atar4qemu@googlemail.com>:
> 2010/4/15 Artyom Tarasenko <atar4qemu@googlemail.com>:
>> 2010/4/15 Blue Swirl <blauwirbel@gmail.com>:
>>> On 4/15/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
>>>> 2010/4/15 Artyom Tarasenko <atar4qemu@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.

-- 
Regards,
Artyom Tarasenko

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

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

[Blue Swirl]

On 4/21/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
> 2010/4/16 Artyom Tarasenko <atar4qemu@googlemail.com>:
>
> > 2010/4/15 Artyom Tarasenko <atar4qemu@googlemail.com>:
>  >> 2010/4/15 Blue Swirl <blauwirbel@gmail.com>:
>  >>> On 4/15/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
>  >>>> 2010/4/15 Artyom Tarasenko <atar4qemu@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.

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

[Artyom Tarasenko]

2010/4/21 Blue Swirl <blauwirbel@gmail.com>:
> On 4/21/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
>> 2010/4/16 Artyom Tarasenko <atar4qemu@googlemail.com>:
>>
>> > 2010/4/15 Artyom Tarasenko <atar4qemu@googlemail.com>:
>>  >> 2010/4/15 Blue Swirl <blauwirbel@gmail.com>:
>>  >>> On 4/15/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
>>  >>>> 2010/4/15 Artyom Tarasenko <atar4qemu@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.

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/