[Top][All Lists]
[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: |
Wed, 21 Apr 2010 01:28:46 +0200 |
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.
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/