From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqCid-0000aD-VL for qemu-devel@nongnu.org; Tue, 22 Sep 2009 17:16:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqCic-0000Zs-De for qemu-devel@nongnu.org; Tue, 22 Sep 2009 17:16:14 -0400 Received: from [199.232.76.173] (port=57503 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqCic-0000Zo-7w for qemu-devel@nongnu.org; Tue, 22 Sep 2009 17:16:14 -0400 Received: from hall.aurel32.net ([88.191.82.174]:33357) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqCib-0007Vw-Tf for qemu-devel@nongnu.org; Tue, 22 Sep 2009 17:16:14 -0400 Received: from aurel32 by hall.aurel32.net with local (Exim 4.69) (envelope-from ) id 1MqCia-0000np-B4 for qemu-devel@nongnu.org; Tue, 22 Sep 2009 23:16:12 +0200 Date: Tue, 22 Sep 2009 23:16:12 +0200 From: Aurelien Jarno Subject: Re: [Qemu-devel] sha1sum segfaults on x86_64 target / i386 host Message-ID: <20090922211612.GC31345@hall.aurel32.net> References: <20090922154949.GA25438@volta.aurel32.net> <761ea48b0909221048h1d1edd9bx4478ae850a0e447b@mail.gmail.com> <20090922190620.GB31345@hall.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090922190620.GB31345@hall.aurel32.net> Sender: Aurelien Jarno List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, Sep 22, 2009 at 09:06:20PM +0200, Aurelien Jarno wrote: > On Tue, Sep 22, 2009 at 07:48:52PM +0200, Laurent Desnogues wrote: > > On Tue, Sep 22, 2009 at 5:49 PM, Aurelien Jarno wrote: > > [...] > > > > > > 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: > > > > > >        /* if too long translation, stop generation too */ > > >        if (gen_opc_ptr >= gen_opc_end || > > >            (pc_ptr - pc_start) >= (TARGET_PAGE_SIZE - 32) || > > >            num_insns >= max_insns) { > > >            gen_jmp_im(pc_ptr - dc->cs_base); > > >            gen_eob(dc); > > >            break; > > >        } > > > > > > 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: > > > > > >    /* Leave some spare opc slots for branch handling. */ > > >    gen_opc_end = 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? > > Exactly, or even reverting his commit on the current tree. > > > 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). > > > > I have played a bit with this number, it seems the buffer is too short > by 3 opc. > After some debugging with Laurent on IRC (thanks!), the problem is that some instructions (e.g. ror $0x1b,%eax) can generate up to 77 tcg op. This is not consistent with this line from exec-all.h: #define MAX_OP_PER_INSTR 64 -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net