qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Artyom Tarasenko
Subject: [Qemu-devel] Re: sparc32 FPU SP Invalid CEXC Test
Date: Fri, 16 Apr 2010 16:37:55 +0200

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)

-- 
Regards,
Artyom Tarasenko

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]