From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4hGZ-0006ez-Tr for qemu-devel@nongnu.org; Wed, 21 Apr 2010 17:15:27 -0400 Received: from [140.186.70.92] (port=42181 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4hGV-0006Wq-1A for qemu-devel@nongnu.org; Wed, 21 Apr 2010 17:15:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4hGR-0007o0-8t for qemu-devel@nongnu.org; Wed, 21 Apr 2010 17:15:22 -0400 Received: from mail-ww0-f45.google.com ([74.125.82.45]:41346) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4hGO-0007nd-Cb for qemu-devel@nongnu.org; Wed, 21 Apr 2010 17:15:19 -0400 Received: by wwd20 with SMTP id 20so378303wwd.4 for ; Wed, 21 Apr 2010 14:15:14 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Wed, 21 Apr 2010 23:14:54 +0200 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: sparc32 FPU SP Invalid CEXC Test List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel 2010/4/21 Blue Swirl : > On 4/21/10, Artyom Tarasenko wrote: >> 2010/4/16 Artyom Tarasenko : >> >> > 2010/4/15 Artyom Tarasenko : >> =A0>> 2010/4/15 Blue Swirl : >> =A0>>> On 4/15/10, Artyom Tarasenko wrote: >> =A0>>>> 2010/4/15 Artyom Tarasenko : >> =A0>>>> >> =A0>>>> > One of LX's tests crashes pretty hard, causing qemu abort. >> =A0>>>> =A0> I've tried to look how does the execution flow works with -= d in_asm. >> =A0>>>> =A0> Does the address in the log show the guest's PC register? >> =A0>>>> >> =A0>>>> >> =A0>>>> It's probably sort of a "timing" issue. >> =A0>>>> >> =A0>>>> =A0Can we check exceptions not just on jumps, but also on floati= ng poit >> =A0>>>> =A0operations which may cause a trap? >> =A0>>>> =A0These traps are supposed to be syncronous. >> =A0>>> >> =A0>>> Yes, the bug is that PC and NPC are not saved before executing FP= U >> =A0>>> instructions. Please try this patch. >> =A0>> >> =A0>> The patch gets it a couple of tests further: >> =A0>> >> =A0>> FPU SP Invalid CEXC Test >> =A0>> FPU SP Overflow CEXC Test >> =A0>> FPU SP Divide-by-0 CEXC Test >> =A0>> FPU SP Inexact CEXC Test >> =A0>> FPU SP Trap Priority > =A0Test Unassigned mem write access of 4 by= tes to >> =A0>> 000000008421f000 from 700030f8 >> =A0>> >> =A0>> FPU SP Trap Priority < =A0Test >> =A0>> =A0 =A0 ERROR : Unexpected Synchronous Trap Taken, Trap Type =3D 0= 0000008, >> =A0>> PSR =3D 414010c4, PC =3D 70003190, TBR =3D 00000080 >> =A0>> =A0 =A0 STATUS : Entering scope loop .... Press key to Abort!q= emu: >> =A0>> fatal: Trap 0x03 while interrupts disabled, Error state >> =A0>> pc: 0000217c =A0npc: 00003170 >> =A0>> General Registers: >> =A0>> %g0-7: 00000000 00003170 00000055 00000001 00000002 00000000 00000= 000 00000000 >> =A0>> >> =A0>> Current Register Window: >> =A0>> %o0-7: 00000000 00000999 00000000 00000000 00000000 00000000 0001f= ba0 7000971c >> =A0>> %l0-7: 0002fff8 00000000 00000000 00000000 00000000 ffffffff 00000= 000 00000000 >> =A0>> %i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000= 000 00000000 >> =A0>> >> =A0>> Floating Point Registers: >> =A0>> %f00: 000000002.890625 000000025.000000 000000000.000000 000000000= .000000 >> =A0>> %f04: 000000002.890625 000000000.000000 000000002.890625 000000000= .000000 >> =A0>> %f08: 000000003.390625 000000000.000000 000000002.250000 000000000= .000000 >> =A0>> %f12: 000000002.890625 000000000.000000 000000002.312500 000000000= .000000 >> =A0>> %f16: 000000002.312500 000000000.000000 000000002.890625 000000000= .000000 >> =A0>> %f20: 000000002.718750 000000000.000000 000000002.562500 000000000= .000000 >> =A0>> %f24: 000000002.890625 000000000.000000 000000002.968750 000000000= .000000 >> =A0>> %f28: 000000002.312500 000000000.000000 000000002.890625 000000000= .000000 >> =A0>> psr: 41000000 (icc: ---- SPE: ---) wim: 00000002 >> =A0>> fsr: 0f884002 y: 00000000 >> =A0>> Aborted >> =A0>> >> =A0>> >> =A0>> The code: >> =A0>> >> =A0>> =A0 0x70003174: =A0sethi =A0%hi(0x41c80000), %l3 >> =A0>> =A0 0x70003178: =A0add =A0%l4, 2, %l5 >> =A0>> =A0 0x7000317c: =A0st =A0%l3, [ %l4 ] >> =A0>> =A0 0x70003180: =A0ld =A0[ %l4 ], %f1 >> =A0>> =A0 0x70003184: =A0clr =A0[ %l4 ] >> =A0>> =A0 0x70003188: =A0ld =A0[ %l4 ], %f2 >> =A0>> =A0 0x7000318c: =A0mov =A07, %g5 >> =A0>> =A0 0x70003190: =A0fdivs =A0%f1, %f2, %f3 >> =A0> >> =A0> And what is even more strange it looks in qemu.log like if trap is = taken, >> =A0> gdb doesn't stop at the 0x080 breakpoint after this operation. >> =A0> Whether I do a stepi or nexti, it just continues up to the crash. >> =A0> Let me know if I can provide more information. >> =A0> >> =A0> Breakpoint 2, 0x00000080 in ?? () >> =A0> (gdb) cont >> =A0> Continuing. >> =A0> >> =A0> Breakpoint 6, 0x70003190 in ?? () >> =A0> (gdb) stepi >> =A0> Remote connection closed >> =A0> (gdb) >> >> >> The trick was not to set the breakpoint at 0x70003190. Then the >> =A0breakpoint at 0x80 works. >> =A0And I think I found a hint: >> >> =A0http://www.cmpe.boun.edu.tr/courses/cmpe511/fall2004/Ozan Aktan - >> =A0Supersparc Architecture.doc >> >> =A0"One unique feature of the floating-point unit is that dependent >> =A0floating-point instructions may be issued in the same instruction >> =A0group as the dependent floating-point operation. As an example, the >> =A0following instructions can issue in a single clock cycle: >> =A0LDD =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [%i0 + %i1], %f2 >> =A0FMULD =A0 =A0 =A0 =A0 =A0 =A0 =A0%f2, %f4, %f6 =A0 " >> >> =A0We also have a dependent instructions >> >> 0x700030f4: =A0fdivs =A0%f1, %f2, %f3 >> =A00x700030f8: =A0st =A0%f3, [ %l6 ] >> >> >> which must produce two traps simultaneously: division by zero and >> =A0unaligned access. Unaligned access is a higher priority trap, so it >> =A0must be processed first. >> >> =A0In the previous test (which passed) the store produces a data access >> =A0exception which has lower priority than division by zero. The test >> =A0passes 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. --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/