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

[Damion Yates]

On Tue, 11 May 2010, Richard Henderson wrote:

> On 05/11/2010 10:08 AM, Damion Yates wrote:
> > Also is there some magic in gnemul-x86 beyond being a set of x86
> > libs?
> 
> No.

Okay, good to know.
 
> > Does it do any shortcutting to system calls in native rather than
> > sticking with the libs under emulation more?
> 
> No.

Okay, fine.  I expect this has been thought of (or dismissed as not
feasible) on the qemu mailing list over the years anyway.
 
> > Could you explain what you did?  I've tried the following:
> 
> Use the binfmt_misc filesystem to set up qemu as the interpreter for
> x86 binaries.

Did that (mentioned in the original email).  I think what I must have
missed was making sure the qemu binary was found in matching paths in
the chroot (in fact it's probably not needed outside the chroot really).

I'm not quite sure how I missed that, I know what I'm doing but I think
I just lacked faith in whether this could work at all on a fundamental
level.  Of course that was since confirmed on this list, so I just
needed to try again harder.
 
> > chroot ch/ ./ld-linux-arm.so --library-path `pwd`/armlibs \
> > ./qemu-i386 bin/sh
> 
> You may find it easier to staticly link the arm qemu in that case.

Yeah, I figured this was going to be the only way, it was that or the
interpreter after the #! within any wrapper to run stuff.  As I didn't
even have a static sh (arm) around, I rechecked the build of qemu and
found it trivial to statically compile*.

I've now got it working as planned, I can chroot in, I've bind mounted
/tmp/.X11-unix/ in to the chroot so X works (I think my phone has
X with -nolisten tcp and changing that is phone-brickingly scary).

So yeah... everything sort of works.  I can run arbitrary (fairly)
complex binaries like screen, xterm (both need to fork), graphical stuff
like XV and of course wine sol.exe (which I think does some threading)!

http://www.youtube.com/damionyates2

Thanks for all your help.

I still have some issues, surprisingly a few reboots, which is odd as
I'm su'ed to a user after needing root for the chroot, I suspect
something I'm mapping with /dev/ or /proc/ mounts.  I've found although
a lot of stuff doesn't work if it needs those mounts working, my tests
are more reliable for the binaries that don't need /proc or /dev being
there, if I don't mount /proc or bindmount /dev/pts at all.  It's also
not quite doing what I want in terms of wine capabilities.  I suspect
the revisions of x86 libs and wine version, possibly NPTL.  But I think
the wine mailing list is the next best stop for me for that unless any
of you are particularly interested in this?

The other threads on this list are all developery with loads of patches
and stuff so I'll stop annoying you all now and close this thread as a
success :)

Damion

*This is increasingly hard, I think many modern GNU projects have given
up providing a way to statically link stuff, and so many things pull in
via dlopen now you can't even tell from an ldd whether it's likely to
work.

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