From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mq7cr-0000AD-I0 for qemu-devel@nongnu.org; Tue, 22 Sep 2009 11:49:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mq7cp-00009P-T7 for qemu-devel@nongnu.org; Tue, 22 Sep 2009 11:49:57 -0400 Received: from [199.232.76.173] (port=43838 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mq7cp-00009I-JF for qemu-devel@nongnu.org; Tue, 22 Sep 2009 11:49:55 -0400 Received: from hall.aurel32.net ([88.191.82.174]:35224) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mq7cp-0005Lz-4I for qemu-devel@nongnu.org; Tue, 22 Sep 2009 11:49:55 -0400 Date: Tue, 22 Sep 2009 17:49:49 +0200 From: Aurelien Jarno Message-ID: <20090922154949.GA25438@volta.aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] sha1sum segfaults on x86_64 target / i386 host List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, In qemu 0.10.X, sha1sum or gnupg segfault (both user and system mode) when used on i386 host / x86_64 target. This has been fixed in trunk by the following commit. | commit 8cd6345d00a25ffa8828bce31154c88f76fb7fc6 | Author: malc | Date: Thu Apr 2 22:54:35 2009 +0000 | | Immediate versions of ro[lr] | | git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6968 c046a42c-6fe2-441c-8c8c-71466251a162 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? Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net