From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4MsT-0005hd-PD for qemu-devel@nongnu.org; Tue, 20 Apr 2010 19:29:14 -0400 Received: from [140.186.70.92] (port=52620 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4MsQ-0005gs-Nb for qemu-devel@nongnu.org; Tue, 20 Apr 2010 19:29:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4MsN-00006I-HM for qemu-devel@nongnu.org; Tue, 20 Apr 2010 19:29:10 -0400 Received: from mail-wy0-f173.google.com ([74.125.82.173]:38816) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4MsN-00006C-9P for qemu-devel@nongnu.org; Tue, 20 Apr 2010 19:29:07 -0400 Received: by wyb35 with SMTP id 35so2899294wyb.4 for ; Tue, 20 Apr 2010 16:29:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Artyom Tarasenko Date: Wed, 21 Apr 2010 01:28:46 +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/16 Artyom Tarasenko : > 2010/4/15 Artyom Tarasenko : >> 2010/4/15 Blue Swirl : >>> On 4/15/10, Artyom Tarasenko wrote: >>>> 2010/4/15 Artyom Tarasenko : >>>> >>>> > One of LX's tests crashes pretty hard, causing qemu abort. >>>> =A0> I've tried to look how does the execution flow works with -d in_a= sm. >>>> =A0> Does the address in the log show the guest's PC register? >>>> >>>> >>>> It's probably sort of a "timing" issue. >>>> >>>> =A0Can we check exceptions not just on jumps, but also on floating poi= t >>>> =A0operations which may cause a trap? >>>> =A0These 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 > =A0Test Unassigned mem write access of 4 bytes to >> 000000008421f000 from 700030f8 >> >> FPU SP Trap Priority < =A0Test >> =A0 =A0 ERROR : Unexpected Synchronous Trap Taken, Trap Type =3D 0000000= 8, >> PSR =3D 414010c4, PC =3D 70003190, TBR =3D 00000080 >> =A0 =A0 STATUS : Entering scope loop .... Press key to Abort!qemu: >> fatal: Trap 0x03 while interrupts disabled, Error state >> pc: 0000217c =A0npc: 00003170 >> General Registers: >> %g0-7: 00000000 00003170 00000055 00000001 00000002 00000000 00000000 00= 000000 >> >> Current Register Window: >> %o0-7: 00000000 00000999 00000000 00000000 00000000 00000000 0001fba0 70= 00971c >> %l0-7: 0002fff8 00000000 00000000 00000000 00000000 ffffffff 00000000 00= 000000 >> %i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00= 000000 >> >> Floating Point Registers: >> %f00: 000000002.890625 000000025.000000 000000000.000000 000000000.00000= 0 >> %f04: 000000002.890625 000000000.000000 000000002.890625 000000000.00000= 0 >> %f08: 000000003.390625 000000000.000000 000000002.250000 000000000.00000= 0 >> %f12: 000000002.890625 000000000.000000 000000002.312500 000000000.00000= 0 >> %f16: 000000002.312500 000000000.000000 000000002.890625 000000000.00000= 0 >> %f20: 000000002.718750 000000000.000000 000000002.562500 000000000.00000= 0 >> %f24: 000000002.890625 000000000.000000 000000002.968750 000000000.00000= 0 >> %f28: 000000002.312500 000000000.000000 000000002.890625 000000000.00000= 0 >> psr: 41000000 (icc: ---- SPE: ---) wim: 00000002 >> fsr: 0f884002 y: 00000000 >> Aborted >> >> >> The code: >> >> =A0 0x70003174: =A0sethi =A0%hi(0x41c80000), %l3 >> =A0 0x70003178: =A0add =A0%l4, 2, %l5 >> =A0 0x7000317c: =A0st =A0%l3, [ %l4 ] >> =A0 0x70003180: =A0ld =A0[ %l4 ], %f1 >> =A0 0x70003184: =A0clr =A0[ %l4 ] >> =A0 0x70003188: =A0ld =A0[ %l4 ], %f2 >> =A0 0x7000318c: =A0mov =A07, %g5 >> =A0 0x70003190: =A0fdivs =A0%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. --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/