From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D3J9C-0003I3-27 for qemu-devel@nongnu.org; Mon, 21 Feb 2005 14:23:10 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D3J8y-00035L-6n for qemu-devel@nongnu.org; Mon, 21 Feb 2005 14:22:56 -0500 Received: from [129.104.30.34] (helo=mx1.polytechnique.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D3Ijy-0008Ew-S3 for qemu-devel@nongnu.org; Mon, 21 Feb 2005 13:57:07 -0500 Received: from [84.99.204.228] (228.204.99-84.rev.gaoland.net [84.99.204.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTP id AF52733170 for ; Mon, 21 Feb 2005 19:57:03 +0100 (CET) Message-ID: <421A2F44.9040304@bellard.org> Date: Mon, 21 Feb 2005 19:58:12 +0100 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Patch to fix Mac OS X compilation References: <6a3c367237141a46e9d50c2806a212c0@elis.ugent.be> <67020f2e144efbf20ea9d0eb09315239@elis.ugent.be> <87491237e8d0eaafae0d0da9f45799de@elis.ugent.be> In-Reply-To: <87491237e8d0eaafae0d0da9f45799de@elis.ugent.be> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Jonas Maebe wrote: > > On 19 feb 2005, at 21:00, Jonas Maebe wrote: > >> And again a more improved patch (I think). This one includes a special >> case/hack for Mac OS X for __op_gen_label. Now qemu doesn't crash >> anymore when trying to boot freedos, but it doesn't show anything >> either. I just get a black screen. The same goes for reactos, so I >> guess it's some endless loop while emulating the bios or so. > > > Here's the semi-final fix (stupid bug in my previous patch). FreeDos can > now boot, so long as you do not load any drivers. The reason is that the > emulation of the loope instruction goes wrong, and that instruction is > used in himem.sys (but does not occur when booting without it). The > problem is that this is the assembler code generated by gcc for op_loopzw: > > 0x74370 : mflr r0 > 0x74374 : stw r0,8(r1) > 0x74378 : stwu r1,-64(r1) > 0x7437c : lwz r0,48(r27) > 0x74380 : rlwinm r0,r0,3,0,28 > 0x74384 : lis r2,12 > 0x74388 : lwz r2,-16636(r2) > 0x7438c : lwzx r12,r2,r0 > 0x74390 : mtctr r12 > 0x74394 : bctrl > 0x74398 : lhz r0,6(r27) > 0x7439c : cmpwi cr7,r0,0 > 0x743a0 : beq- cr7,0x743b0 > 0x743a4 : andi. r0,r3,64 > 0x743a8 : beq- 0x743b0 > 0x743ac : b 0x296eb0 <__op_gen_label1> > 0x743b0 : lwz r0,72(r1) > 0x743b4 : addi r1,r1,64 > 0x743b8 : mtlr r0 > > > At address 0x743ac, the branch to __op_gen_label1 gets patched so it > points to the basic block coming after the loopzw. In that case, LR does > not get restored (it was destroyed at 0x74394 by the bctrl), so the next > blr which gets executed returns to 0x74398. This causes an endless loop, > obviously. > > This does not seem to be Mac OS X-specific at all, and should also > happen under Linux/ppc I think. I do not see in your patch any fix for the PARAMn bug. The symptom is: translate.c:x: error: too many arguments to function `gen_op_xxx' translate.c:x: warning: initialization from incompatible pointer type I am using gcc 3.3. The problem is related to the fact that '__op_paramN' is no longer exported in the symbol table. Fabrice.