From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IO98J-0006RK-82 for qemu-devel@nongnu.org; Thu, 23 Aug 2007 05:37:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IO98H-0006QX-60 for qemu-devel@nongnu.org; Thu, 23 Aug 2007 05:37:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IO98F-0006QN-8Z for qemu-devel@nongnu.org; Thu, 23 Aug 2007 05:37:39 -0400 Received: from mx2.suse.de ([195.135.220.15]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IO98E-0005fY-NT for qemu-devel@nongnu.org; Thu, 23 Aug 2007 05:37:38 -0400 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 64D8921879 for ; Thu, 23 Aug 2007 11:37:35 +0200 (CEST) From: Ulrich Hecht Subject: Re: [Qemu-devel] Porting QEMU to Minix - op_goto_tb1 segfaults because tb_next[1] is NULL Date: Thu, 23 Aug 2007 11:37:27 +0200 References: <000301c7e4eb$24b81600$0200a8c0@Feanor> In-Reply-To: <000301c7e4eb$24b81600$0200a8c0@Feanor> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200708231137.28138.uli@suse.de> Content-Transfer-Encoding: quoted-printable 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 Wednesday 22 August 2007, Erik van der Kouwe wrote: > My problem is the following: quickly after starting I get a > segmentation fault while the generated code is running. > > This happens in the code generated from op_goto_tb1 and is caused by > jumping to a NULL pointer. This NULL pointer originates from the > tb_next[1] field of the translation block data structure passed as a > parameter. I have verified in the disassembler that the parameter in > the generated code is processed correctly and the field is indeed > tb_next[1]. I had a similar problem when fixing S/390 hosts. IIRC it was caused by=20 the "portable" GOTO_TB macro. On translation the goto is patched to jump=20 out of the block, which is something the compiler does not reckon with.=20 You may want to disassemble it and check if registers are overwritten=20 before the jump takes place. CU Uli --=20 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N=FCrnberg)