From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KUywK-0000aZ-KA for qemu-devel@nongnu.org; Mon, 18 Aug 2008 03:14:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KUywJ-0000aH-6o for qemu-devel@nongnu.org; Mon, 18 Aug 2008 03:14:07 -0400 Received: from [199.232.76.173] (port=37600 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KUywJ-0000aE-1E for qemu-devel@nongnu.org; Mon, 18 Aug 2008 03:14:07 -0400 Received: from mx20.gnu.org ([199.232.41.8]:44473) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KUywJ-0007gN-5l for qemu-devel@nongnu.org; Mon, 18 Aug 2008 03:14:07 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KUywH-0002wG-Ls for qemu-devel@nongnu.org; Mon, 18 Aug 2008 03:14:06 -0400 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate01.web.de (Postfix) with ESMTP id E30A6EB5514F for ; Mon, 18 Aug 2008 09:14:04 +0200 (CEST) Received: from [88.65.45.230] (helo=[192.168.1.198]) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1KUywG-0002UK-00 for qemu-devel@nongnu.org; Mon, 18 Aug 2008 09:14:04 +0200 Message-ID: <48A9212B.9090302@web.de> Date: Mon, 18 Aug 2008 09:13:47 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <761ea48b0807160530k59412f39p6ae0c90c2756fb58@mail.gmail.com> <487DEB2D.5040302@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig85F2922414C6B520116F19A1" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [4875] Remove unintended dereference, kills a warning (Jan Kiszka). 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig85F2922414C6B520116F19A1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable andrzej zaborowski wrote: > 2008/7/16 Jan Kiszka : >> Laurent Desnogues wrote: >>> On Wed, Jul 16, 2008 at 2:04 PM, Andreas Schwab wrot= e: >>>> Andrzej Zaborowski writes: >>>> >>>>> void OPPROTO op_tasb_rN(void) >>>>> { >>>>> - cond_t(*(int8_t *) env->gregs[PARAM1] =3D=3D 0); >>>>> - *(int8_t *) env->gregs[PARAM1] |=3D 0x80; >>>>> + cond_t((env->gregs[PARAM1] && 0xff) =3D=3D 0); >>>>> + *(int8_t *) &env->gregs[PARAM1] |=3D 0x80; >>>> That does not make any sense at all. The TAS insn operates on memor= y, >>>> not on a register (atomic operations only make sense on memory anywa= y). >>> SH4 documentation says this: >>> >>> TAS.B @Rn >>> If (Rn) =3D 0, 1 =E2=86=92 T, else 0 =E2=86=92 T >>> 1 =E2=86=92 MSB of (Rn) >>> >>> So indeed it looks like Jan and Andrzej patch is wrong. >> At least the audience is finally listening. ;) >> >> Is this one better? >=20 > I suspect one of these may be more correct, but I haven't seen the > docs. The below, like the original version, assumes that if the store > generates some kind of trap, the flag is still affected. Otherwise > cond_t needs to be the last. >=20 > diff --git a/target-sh4/op.c b/target-sh4/op.c > --- a/target-sh4/op.c > +++ b/target-sh4/op.c > @@ -592,13 +592,6 @@ void OPPROTO op_shlr16_Rn(void) > RETURN(); > } >=20 > -void OPPROTO op_tasb_rN(void) > -{ > - cond_t((env->gregs[PARAM1] & 0xff) =3D=3D 0); > - *(int8_t *) &env->gregs[PARAM1] |=3D 0x80; > - RETURN(); > -} > - > void OPPROTO op_movl_T0_rN(void) > { > env->gregs[PARAM1] =3D T0; > diff --git a/target-sh4/translate.c b/target-sh4/translate.c > --- a/target-sh4/translate.c > +++ b/target-sh4/translate.c > @@ -1077,7 +1077,12 @@ void _decode_opc(DisasContext * ctx) > gen_op_shlr16_Rn(REG(B11_8)); > return; > case 0x401b: /* tas.b @Rn */ > - gen_op_tasb_rN(REG(B11_8)); > + gen_op_movl_rN_T0(REG(B11_8)); > + gen_op_movl_T0_T1(); > + gen_op_ldub_T0_T0(ctx); > + gen_op_cmp_eq_imm_T0(0); > + gen_op_or_imm_T0(0x80); > + gen_op_stb_T0_T1(ctx); > return; > case 0xf00d: /* fsts FPUL,FRn - FPSCR: Nothing */ > gen_op_movl_fpul_FT0(); >=20 > or >=20 > diff --git a/target-sh4/op.c b/target-sh4/op.c > --- a/target-sh4/op.c > +++ b/target-sh4/op.c > @@ -592,13 +592,6 @@ void OPPROTO op_shlr16_Rn(void) > RETURN(); > } >=20 > -void OPPROTO op_tasb_rN(void) > -{ > - cond_t((env->gregs[PARAM1] & 0xff) =3D=3D 0); > - *(int8_t *) &env->gregs[PARAM1] |=3D 0x80; > - RETURN(); > -} > - > void OPPROTO op_movl_T0_rN(void) > { > env->gregs[PARAM1] =3D T0; > diff --git a/target-sh4/op_mem.c b/target-sh4/op_mem.c > --- a/target-sh4/op_mem.c > +++ b/target-sh4/op_mem.c > @@ -76,3 +76,10 @@ void glue(op_stfq_DT0_T1, MEMSUFFIX) (void) { > glue(stfq, MEMSUFFIX) (T1, DT0); > RETURN(); > } > + > +void glue(op_tasb_Rn, MEMSUFFIX) (void) { > + uint8_t val =3D glue(ldub, MEMSUFFIX) (env->gregs[PARAM1]); > + cond_t(val =3D=3D 0); > + glue(stb, MEMSUFFIX) (env->gregs[PARAM1], val | 0x80); > + RETURN(); > +} > diff --git a/target-sh4/translate.c b/target-sh4/translate.c > --- a/target-sh4/translate.c > +++ b/target-sh4/translate.c > @@ -80,6 +80,10 @@ static void sh4_translate_init() > gen_op_st##width##_##reg##_T1_raw(); \ > } >=20 > +void gen_op_tasb_Rn(DisasContext *ctx, int reg) { > + gen_op_tasb_Rn_raw(reg); > +} > + > #else >=20 > #define GEN_OP_LD(width, reg) \ > @@ -93,6 +97,13 @@ static void sh4_translate_init() > else gen_op_st##width##_##reg##_T1_user();\ > } >=20 > +void gen_op_tasb_Rn(DisasContext *ctx, int reg) { > + if (ctx->memidx) > + gen_op_tasb_Rn_kernel(reg); > + else > + gen_op_tasb_Rn_user(reg); > +} > + > #endif >=20 > GEN_OP_LD(ub, T0) > @@ -1077,7 +1088,7 @@ void _decode_opc(DisasContext * ctx) > gen_op_shlr16_Rn(REG(B11_8)); > return; > case 0x401b: /* tas.b @Rn */ > - gen_op_tasb_rN(REG(B11_8)); > + gen_op_tasb_Rn(ctx, REG(B11_8)); > return; > case 0xf00d: /* fsts FPUL,FRn - FPSCR: Nothing */ > gen_op_movl_fpul_FT0(); This proposed fix for an open bug is about to be forgotten again. Can anyone with SH4 experience comment on it? Jan --------------enig85F2922414C6B520116F19A1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkipIToACgkQniDOoMHTA+kVXwCcDf8CV+Q7+qa6djUs4ySgZ+cg AasAnitINa/s74BfL7WP+Q34/wutPfk4 =BfwJ -----END PGP SIGNATURE----- --------------enig85F2922414C6B520116F19A1--