From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LeGtV-00017H-Hg for qemu-devel@nongnu.org; Mon, 02 Mar 2009 17:45:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LeGtT-00016m-Ab for qemu-devel@nongnu.org; Mon, 02 Mar 2009 17:45:52 -0500 Received: from [199.232.76.173] (port=52647 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeGtS-00016X-Sb for qemu-devel@nongnu.org; Mon, 02 Mar 2009 17:45:51 -0500 Received: from fg-out-1718.google.com ([72.14.220.156]:19203) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LeGtS-0006z5-DY for qemu-devel@nongnu.org; Mon, 02 Mar 2009 17:45:50 -0500 Received: by fg-out-1718.google.com with SMTP id e21so1015011fga.8 for ; Mon, 02 Mar 2009 14:45:48 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1236013674-28082-2-git-send-email-agraf@suse.de> References: <1236013674-28082-1-git-send-email-agraf@suse.de> <1236013674-28082-2-git-send-email-agraf@suse.de> Date: Mon, 2 Mar 2009 23:45:47 +0100 Message-ID: <761ea48b0903021445r3dd81ad6xec46e1919ed9e5a0@mail.gmail.com> Subject: Re: [Qemu-devel] [PATCH 1/3] PPC: Circumvent overflow in mtcrf From: Laurent Desnogues Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 On Mon, Mar 2, 2009 at 6:07 PM, Alexander Graf wrote: > I had a segmentation fault in mtcrf, where ffs() returned 8 and the > code then accessed cpu_crf[7 - 8]. > > In order to circumvent this, I just put in an & 7 to the ffs result, > so we'll never run negative. This is probably not correct, but makes > things work for me so far. > > Signed-off-by: Alexander Graf > --- > target-ppc/translate.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/target-ppc/translate.c b/target-ppc/translate.c > index 2a06e4c..2e7420f 100644 > --- a/target-ppc/translate.c > +++ b/target-ppc/translate.c > @@ -3937,7 +3937,7 @@ GEN_HANDLER(mtcrf, 0x1F, 0x10, 0x04, 0x00000801, PPC_MISC) > crm = CRM(ctx->opcode); > if (likely((ctx->opcode & 0x00100000) || (crm ^ (crm - 1)) == 0)) { > TCGv_i32 temp = tcg_temp_new_i32(); > - crn = ffs(crm); > + crn = ffs(crm) & 7; > tcg_gen_trunc_tl_i32(temp, cpu_gpr[rS(ctx->opcode)]); > tcg_gen_shri_i32(cpu_crf[7 - crn], temp, crn * 4); > tcg_gen_andi_i32(cpu_crf[7 - crn], cpu_crf[7 - crn], 0xf); I think the problem lies in the if; could you try this? if (likely((ctx->opcode & 0x00100000)) if (crm ^ (crm - 1)) == 0) { TCGv_i32 temp = tcg_temp_new_i32(); crn = ffs(crm); tcg_gen_trunc_tl_i32(temp, cpu_gpr[rS(ctx->opcode)]); tcg_gen_shri_i32(cpu_crf[7 - crn], temp, crn * 4); tcg_gen_andi_i32(cpu_crf[7 - crn], cpu_crf[7 - crn], 0xf); tcg_temp_free_i32(temp); } } else { The Power spec says mtocrf is undefined if crm has not exactly one bit set. The patch above will just make it a nop (and will also generate code for mtcrf when it should instead of wrongly generating buggy code for mtocrf when crm is a power of 2 no matter what bit 20 [or bit 11 in dumb reversed bit numbering scheme of Power] is). Laurent