From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mq9U4-00067v-Ol
	for qemu-devel@nongnu.org; Tue, 22 Sep 2009 13:49:00 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mq9Tz-00065T-Uu
	for qemu-devel@nongnu.org; Tue, 22 Sep 2009 13:49:00 -0400
Received: from [199.232.76.173] (port=43356 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mq9Tz-00065H-Ky
	for qemu-devel@nongnu.org; Tue, 22 Sep 2009 13:48:55 -0400
Received: from mail-fx0-f214.google.com ([209.85.220.214]:65368)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <laurent.desnogues@gmail.com>) id 1Mq9Tz-0001VY-6R
	for qemu-devel@nongnu.org; Tue, 22 Sep 2009 13:48:55 -0400
Received: by fxm10 with SMTP id 10so3061016fxm.8
	for <qemu-devel@nongnu.org>; Tue, 22 Sep 2009 10:48:53 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20090922154949.GA25438@volta.aurel32.net>
References: <20090922154949.GA25438@volta.aurel32.net>
Date: Tue, 22 Sep 2009 19:48:52 +0200
Message-ID: <761ea48b0909221048h1d1edd9bx4478ae850a0e447b@mail.gmail.com>
Subject: Re: [Qemu-devel] sha1sum segfaults on x86_64 target / i386 host
From: Laurent Desnogues <laurent.desnogues@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: qemu-devel@nongnu.org

On Tue, Sep 22, 2009 at 5:49 PM, Aurelien Jarno <aurelien@aurel32.net> wrot=
e:
[...]
>
> Actually I am not really convinced it has been fixed, I really think the
> bug is still present, but not triggerable anymore this way.
>
> It looks like very long translation are not stopped correctly. This part
> of code looks suspicious:
>
> =A0 =A0 =A0 =A0/* if too long translation, stop generation too */
> =A0 =A0 =A0 =A0if (gen_opc_ptr >=3D gen_opc_end ||
> =A0 =A0 =A0 =A0 =A0 =A0(pc_ptr - pc_start) >=3D (TARGET_PAGE_SIZE - 32) |=
|
> =A0 =A0 =A0 =A0 =A0 =A0num_insns >=3D max_insns) {
> =A0 =A0 =A0 =A0 =A0 =A0gen_jmp_im(pc_ptr - dc->cs_base);
> =A0 =A0 =A0 =A0 =A0 =A0gen_eob(dc);
> =A0 =A0 =A0 =A0 =A0 =A0break;
> =A0 =A0 =A0 =A0}
>
> If I understand correctly, when the end of the buffer is reached, the
> translation is stopped, but some more opc are added by gen_jmp_im()
> and gen_eob().
>
> OTOH, on MIPS the following code leaves some space at the end of the
> buffer for a few more opc:
>
> =A0 =A0/* Leave some spare opc slots for branch handling. */
> =A0 =A0gen_opc_end =3D gen_opc_buf + OPC_MAX_SIZE - 16;
>
> Applying the same changes to the x86_64 target fixes the bug. However, I
> am not sure it is fully correct. Any comment?

You mean that if you sub 16 and go back just previous malc's commit
you don't experience the crash anymore?

To me it looks like using gen_opc_buf + OPC_MAX_SIZE is rather
safe given that it gives room for 64 extra ops (cf exec-all.h).


Laurent