From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LArtl-0002S9-Q6 for qemu-devel@nongnu.org; Thu, 11 Dec 2008 15:12:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LArtj-0002Rs-SH for qemu-devel@nongnu.org; Thu, 11 Dec 2008 15:12:37 -0500 Received: from [199.232.76.173] (port=47940 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LArtj-0002Rp-Q3 for qemu-devel@nongnu.org; Thu, 11 Dec 2008 15:12:35 -0500 Received: from soufre.accelance.net ([213.162.48.15]:62076) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LArth-0007Es-Dw for qemu-devel@nongnu.org; Thu, 11 Dec 2008 15:12:33 -0500 Received: from [192.168.0.3] (potipota.net [88.168.176.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by soufre.accelance.net (Postfix) with ESMTP id 7EF104503F for ; Thu, 11 Dec 2008 21:12:24 +0100 (CET) Subject: Re: [Qemu-devel] Re: SH4: Implement FD bit From: Lionel Landwerlin In-Reply-To: References: <200812012022.02276.vladimir@codesourcery.com> <20081207224734.GD3591@volta.aurel32.net> Content-Type: text/plain; charset=utf-8 Date: Thu, 11 Dec 2008 21:12:22 +0100 Message-Id: <1229026342.3898.24.camel@cocoduo.atr> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Le mardi 09 d=C3=A9cembre 2008 =C3=A0 19:36 +0300, Vladimir Prus a =C3=A9= crit : > Aurelien Jarno wrote: >=20 > >>=20 > >> SH4 manual say that if a floating point instruction is executed whil= e > >> FD bit in the status register is 1, an exception should be raised. Q= EMU > >> presently does not do that, so the kernel does not initialize FP sta= te > >> for any thread, nor does it save/restore FP state. The most apparent > >> consequence is that while recent gcc/libc expect double-precision mo= de > >> to be set by kernel, they run in single-precision mode, and all FP c= ode > >> produces wrong values. > >>=20 > >> This patch fixes this. It also fixes a couple of places where PC was > >> not updated before handling an exception, although both those places > >> deal with invalid instruction and don't lead to any user-visible bug= s. > >>=20 > >> - Volodya > >=20 > > Thanks, applied. >=20 > Thanks, but it looks like one bit of the patch somehow did not > make it into SVN. Specifically, this: >=20 > @@ -504,6 +523,13 @@ static void _decode_opc(DisasContext * ctx) > } > } > =20 > + /* The 0xfffd instruction is underfined, so we don't want to > + raise fpu disable exception on it. */ > + if (((ctx->opcode & 0xf000) =3D=3D 0xf000) > + && (ctx->opcode !=3D 0xfffd)) =20 > + { > + CHECK_FPU_ENABLED > + } >=20 > Is present in my post, and is not present in: >=20 > http://svn.sv.gnu.org/viewvc/?view=3Drev&root=3Dqemu&revision=3D= 5937 >=20 > Maybe some merge issue? >=20 > Thanks, > Volodya >=20 Vladimir (Volodya ?), you probably know better than me sh4 opcodes, but your patch is breaking = my sh4 user mode emulation. $ ./sh4-linux-user/qemu-sh4 -strace -L /home/djdeath/taff/rootfs/ /middle= ware.dbg 1500 brk(0,0,0,1074264596,1074357772,0) =3D 0x00d98000 1500 uname(0x4007f6aa) =3D 0 1500 access("/etc/ld.so.preload",04) =3D -1 errno=3D2 (No such file or di= rectory) Unhandled trap: 0x800 pc=3D0x400977ea sr=3D0x00008001 pr=3D0x4008eae8 fpscr=3D0x00080000 spc=3D0x00000000 ssr=3D0x00000000 gbr=3D0x00000000 vbr=3D0x00000000 sgr=3D0x00000000 dbr=3D0x00000000 delayed_pc=3D0x400977e0 fpul=3D0x000000= 00 r0=3D0x000000e0 r1=3D0x00000000 r2=3D0x00008cf8 r3=3D0x4400302e r4=3D0x4007f3f0 r5=3D0x00000000 r6=3D0x4007f57b r7=3D0x4008d200 r8=3D0x4007f3b8 r9=3D0x00b37cd0 r10=3D0x00000000 r11=3D0x4007f558 r12=3D0x400ae004 r13=3D0x00000000 r14=3D0x4007f3a4 r15=3D0x4007f3a4 r16=3D0x00000000 r17=3D0x00000000 r18=3D0x00000000 r19=3D0x00000000 r20=3D0x00000000 r21=3D0x00000000 r22=3D0x00000000 r23=3D0x00000000 According to you, should the FD bit be "up" by default in user mode emula= tion ? By putting the FD bit "down" in cpu_sh4_reset(target-sh4/translate.c), I'= m able to restore initial behavior of user mode emulation (that means, qemu does not exits very ear= ly before libc initialization (see the traces before)). Maybe putting down the FD bit should be done in a user mode part only... = I'm wondering... Regards, --=20 =EF=BB=BFLione Landwerlin =20 =EF=BB=BF O p e n W i d e 14, rue Gaillon 75002 Paris