From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcdID-0003A5-I1 for qemu-devel@nongnu.org; Fri, 01 Jul 2011 08:57:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcdIB-0004F9-Mq for qemu-devel@nongnu.org; Fri, 01 Jul 2011 08:57:57 -0400 Received: from mx2.avast.com ([91.213.143.6]:47522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcdIB-0004Eq-08 for qemu-devel@nongnu.org; Fri, 01 Jul 2011 08:57:55 -0400 Message-ID: <4E0DC450.4000700@jermar.eu> Date: Fri, 01 Jul 2011 14:57:52 +0200 From: Jakub Jermar MIME-Version: 1.0 References: <4E0CE6A7.10901@jermar.eu> <4E0D9527.7010106@jermar.eu> In-Reply-To: Content-Type: multipart/mixed; boundary="------------030102040708040109070901" Subject: Re: [Qemu-devel] [HelenOS-devel] [sparc64] Miscomputed minimum of a group of numbers in sparc64 emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: HelenOS development mailing list Cc: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------030102040708040109070901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1.7.2011 12:41, Artyom Tarasenko wrote: > Looks like it's a pretty nice test case. > > The test case scenario is to load the initial values into the > registers (you already know them), > calculate the mins, cmp the result with expected and jump somewhere. > Since it happens with interrupts disabled, we don't need an OS or bios > to test that. The binary just has to have an entry point at 0x20, > then we can load it instead of bios. > > Care to produce the test case? (Otherwise I'll do it, but probably not > until the weekend after the next one). Yes I have a small reproducible testcase, see the attachments. When _not_ singlestepping via GDB's `stepi`, the testcase will fail and crash Qemu like this: qemu: fatal: Trap 0x0101 while trap level (5) >= MAXTL (5), Error state On the other hand, when I attach GDB to Qemu and step through all instructions using `stepi`, the testcase will succeed and crash Qemu like this: qemu: fatal: Trap 0x0100 while trap level (5) >= MAXTL (5), Error state Mind the difference in the trap type - 0x100 for success, 0x101 for failure. This is how I run the test: Without GDB: $ qemu-system-sparc64 -bios ./testcase With GDB: $ qemu-system-sparc64 -bios ./testcase -s -S >>From another terminal: $ /usr/local/cross/sparc64/bin/sparc64-linux-gnu-gdb (gdb) set architecture sparc:v9 (gdb) target remote localhost:1234 (gdb) stepi ... Hope this helps to fix the problem. Jakub --------------030102040708040109070901 Content-Type: text/plain; name="Makefile" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Makefile" .PHONY=all all: rm *.o testcase /usr/local/cross/sparc64/bin/sparc64-linux-gnu-as -g testcase.S -o testcase.o /usr/local/cross/sparc64/bin/sparc64-linux-gnu-ld -Ttext 0x00 testcase.o -o testcase --oformat binary --------------030102040708040109070901 Content-Type: application/octet-stream; name="testcase" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="testcase" AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzAABrshZjObQQIAADAACAhhAgQICm QAOJMGAIgzBgGIgRAAGFKTAwhTCwMIJugAKCSEACs2cQA4ImgAGCIIABgKZAARhoAAMBAAAA kdAgAJHQIAE= --------------030102040708040109070901 Content-Type: text/plain; name="testcase.S" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="testcase.S" .global _start .register %g2, #scratch .register %g3, #scratch .text .space 0x20 _start: set 110393, %i1 set 0, %i2 set 131072, %g1 set 0x40, %g3 cmp %i1, %g3 srl %g1, 8, %g4 srl %g1, 0x18, %g1 or %g4, %g1, %g4 sllx %g4, 0x30, %g2 srlx %g2, 0x30, %g2 udivx %i2, %g2, %g1 mulx %g1, %g2, %g1 movgu %xcc, %g3, %i1 sub %i2, %g1, %g1 sub %g2, %g1, %g1 cmp %i1, %g1 bgu %xcc, 0f nop succ: ta 0 fail: 0: ta 1 --------------030102040708040109070901--