From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NfL8e-0000fM-3G for qemu-devel@nongnu.org; Wed, 10 Feb 2010 17:34:28 -0500 Received: from [199.232.76.173] (port=44182 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NfL8d-0000fB-1d for qemu-devel@nongnu.org; Wed, 10 Feb 2010 17:34:27 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NfL8b-000791-PY for qemu-devel@nongnu.org; Wed, 10 Feb 2010 17:34:26 -0500 Received: from mail-pz0-f180.google.com ([209.85.222.180]:51212) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NfL8b-00078M-8K for qemu-devel@nongnu.org; Wed, 10 Feb 2010 17:34:25 -0500 Received: by pzk10 with SMTP id 10so167858pzk.19 for ; Wed, 10 Feb 2010 14:34:18 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 10 Feb 2010 23:34:17 +0100 Message-ID: <761ea48b1002101434v3950c79em4139f2edabb0d1f7@mail.gmail.com> Subject: Re: [Qemu-devel] forking i386 binaries on arm linux user mode From: Laurent Desnogues Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Damion Yates Cc: qemu-devel@nongnu.org On Wed, Feb 10, 2010 at 10:38 PM, Damion Yates wrote: > I've grabbed the latest stable qemu and compiled under scratchbox. =A0I > hit an issue compiling it, with no __builtin__clear_cache() so linked in > a kludge.c containing a call to __clear_cache() with the params passed > as they would be to __builtin__clear_cache(). > > Firstly does this sound like it should work as a workaround? That's how I did it (except that I replaced the calls to __builtin__clear_cache with calls to __clear_cache in tcg/arm/tcg-target.h and exec-all.h. > It certainly got me to the next level, which is that I can now run loads > of linux binaries on my armlinux system (a Nokia n900). I've tried tower > toppler (http://toppler.sourceforge.net/) which uses SDL (via X11) and > this was surprisingly fast, in fact it almost felt as fast as the native > toppler that somebody crosscompiled already. Most linux utils work when > I copy then and any dependant libs from my x86 laptop to the phone. I'm > lucky (I guess) that /lib/ld-linux.so.3 is the arm version and I'm using > a slightly older .2 for x86 so I can have both files there. I also > enabled arbitrary execution of binaries via binfmt_misc. The 600 Mhz Arm > V8 Cortex (I think it is), feels like it's running at about Pentium 90 > speeds, which I'm hoping is enough for what I really want to get going. The N900 has an ARMv7 Cortex-A8 (OMAP3). P90 is about the speed I'd expect. Note it will seem much slower if your program makes heavy use of floating point. > I want to run an old, possibly win16 Windows game under wine. I saw that > user mode qemu-i386 was able to run wine in a post in 2004: > http://lists.terrasoftsolutions.com/pipermail/yellowdog-general/2004-June= /014468.html - This was on a PPC however. > > When I run wine it SEGVs out and the strace of it shows it dies trying > to do clone(). I also can't run things like xterm which can't do fork(). > Is this because by default it's trying to go via the arm "/bin/sh" to > invoke whatever it wants to exec() in to? > > Should clone()/fork() work? =A0Has anyone been able to run wine ./blah.ex= e > under user-linux mode of qemu on arm or indeed any other non x86 based > CPU ? I have seen a complex Linux i386 program run on an ARM platform (with multithreading and Qt; note it crashed at some point but it was due to the application doing access to uninitialized memory). IIRC it was using chroot from inside QEMU (in main) to make sure that all calls to exec would happen on an x86 file system. You might give that a try. Laurent