qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] forking i386 binaries on arm linux user mode


From: Damion Yates
Subject: Re: [Qemu-devel] forking i386 binaries on arm linux user mode
Date: Tue, 11 May 2010 18:08:25 +0100 (BST)
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)

On Wed, 10 Feb 2010, Laurent Desnogues wrote:

> On Wed, Feb 10, 2010 at 10:38 PM, Damion Yates <address@hidden>
> wrote:
> 
> > 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.

> > 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.

I've also since seen linked via http://wiki.winehq.org/ARM of others
doing this in 2006-09, although no details were posted other than
"installed their gnemul-x86 package. I then went and fetched Debian's
Wine and all its dependencies from their ARM distribution."

It doesn't make sense to use Debian's wine from their ARM dist, maybe he
meant just the wine from x86 circa 2006.

Also is there some magic in gnemul-x86 beyond being a set of x86 libs?
Does it do any shortcutting to system calls in native rather than
sticking with the libs under emulation more?

As I understand it qemu (in the arm compiled x86 user emulation mode I
have it) emulates an x86 to let my arm cpu start to execute x86 elf
binaries.  As soon as that tries to do any system calls, those are able
to run natively on arm, for things like opening files before returning a
pointer to the filehandle etc?  So it's sort of quite fast at times?

With special x86 libs it could also do some clever shortcuts getting in
to native mode sooner at some points?

> > 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?  Has anyone been able to run wine
> > ./blah.exe under user-linux mode of qemu on arm or indeed any other
> > non x86 based CPU ?
> 
[added from other post]
> NPTL is not supported for x86 which will be an issue.

This could be quite problematic, as I believe all recent wine versions
use this.  My running of older versions of wine is likely to lead to a
lack of support when I approach the wine team.

> 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.

Could you explain what you did?  I've tried the following:

ch/ is a small x86 base image (color.gz from slackware).

chroot ch/ ./ld-linux-arm.so --library-path `pwd`/armlibs ./qemu-i386 bin/sh

This works, I'm sat in an x86 bash binary with / and upwards being
mostluy x86 (except ./ld-linux-arm.so, ./qemu-i386 and the armlibs/
directory).  I can run the x86 stuff, with ld-linux.so and qemu but I
can't just do /bin/ls.

I could use statically linked /bin/bash-static on #! path wrappers which
spawn qemu (via an arm ld-linux.so) to fake /bin/sh as an executable,
which would function and would be x86, but I'm confused as to any gain.
Basically I don't think a chroot is the issue.  So...

I tried using the versions of libs and wine from the 2004 post of the
successful PPC wine execution and now get:

~/winefiles $ ../qemu-i386 -L /home/user/winefiles/l lib/ld-2.3.2.so 
usr/bin/wineserver
~/winefiles $ ../qemu-i386 -L /home/user/winefiles/l lib/ld-2.3.2.so 
usr/bin/wine-pthread notepad
Could not stat /mnt/floppy (No such file or directory), ignoring drive A: 
err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, 
please report
err:heap:HEAP_CreateSystemHeap system heap base address 0x65430000 not available

Segmentation fault

~/winefiles $ ../qemu-i386 -L /home/user/winefiles/l lib/ld-2.3.2.so 
usr/bin/wineserver
~/winefiles $ ../qemu-i386 -L /home/user/winefiles/l lib/ld-2.3.2.so 
usr/bin/wine-pthread pscp.exe
Could not stat /mnt/floppy (No such file or directory), ignoring drive A:
err:virtual:map_image Standard load address for a Win32 program
(0x00400000) not available - security-patched kernel ?
wine: could not load L"C:\\windows\\pscp.exe" as Win32 binary
~/winefiles $

I need help from a qemu/wine/armlinux/kernel expert to continue beyond
this.

Oh I should note that I echoed 0 to /proc/sys/vm/max_map_count which is
suggested on the wine forums as the fix for the security-patched kernel
? error.  But this didn't work.

Any ideas?  Should I direct this to wine ?  Is this something anyone is
interested in helping me get working?

Damion

-- 
Damion Yates - Google UK Ltd
Belgrave House, 76 Buckingham Palace Rd, London SW1W 9TQ - reg:3977902

reply via email to

[Prev in Thread] Current Thread [Next in Thread]