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

[Artyom Tarasenko]

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.

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/