Active Topics

 


Reply
Thread Tools
Posts: 173 | Thanked: 160 times | Joined on Jan 2010 @ London, UK
#1
I've managed to run hello world (static at the moment) which is an x86 binary, on my n900 using qemu's user linux mode.

?:/home/opt/root# file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, statically linked, stripped
?:/home/opt/root# file `which file`
/usr/bin/file: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), stripped
?:/home/opt/root# ./qemu-i386-2 ./hello
Hello World
?:/home/opt/root#

Next up, dynamically linked stuff, and then wine ))
 

The Following 21 Users Say Thank You to damion For This Useful Post:
Posts: 173 | Thanked: 160 times | Joined on Jan 2010 @ London, UK
#2
Now with a stock GNU ls from an x86 box, dynamically linked.

?:/home/opt/root/lib# ../qemu-i386-2 ./ld-linux.so.2 --library-path `pwd` ../ls
qemu: Unsupported syscall: 240
ld-linux.so.2 libattr.so.1 libdl.so.2 librt.so.1
libacl.so.1 libc.so.6 libpthread.so.0 libselinux.so.1
?:/home/opt/root/lib#

Don't know what Unsupported syscall: 240 is, but it seems to work and correctly lists files.

Last edited by damion; 2010-02-05 at 15:29. Reason: incomplete
 

The Following 2 Users Say Thank You to damion For This Useful Post:
nowave7's Avatar
Posts: 245 | Thanked: 62 times | Joined on Jan 2009 @ Bad Homburg, Deutschland
#3
A call to system library that is ARM EABI?
__________________
Save the whales, feed the hungry, free the mallocs!
 
Posts: 173 | Thanked: 160 times | Joined on Jan 2010 @ London, UK
#4
My wineserver and wine attempts are failing sadly.

?:/home/opt/root/standalonewine-0.99# strace -s256 -v -fF -o log ../qemu-i386-2 $MYWINEPATH/ld-linux.so.2 --library-path $LDLIBRARY_PATH $MYWINEPATH/wine-pthread
qemu: Unsupported syscall: 240
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

I happened to already have an ld-linux.so spawned wine and wineserver shell wrapper from a different project running missmatched system compiled binaries. However that was on the same arch. This isn't working.

#!/bin/bash
export MYWINEPATH=`pwd`
export WINEPREFIX=`pwd`
export WINEDLLPATH=$MYWINEPATH/dlls
export LDLIBRARY_PATH=$MYWINEPATH/libs
../qemu-i386-2 $MYWINEPATH/ld-linux.so.2 --library-path $LDLIBRARY_PATH $MYWINEPATH/wineserver.bin

Anyone have any ideas what to try next? qemu mailing list, wine mailing list ?
 
nowave7's Avatar
Posts: 245 | Thanked: 62 times | Joined on Jan 2009 @ Bad Homburg, Deutschland
#5
Hve you tried looking into the core dump? Even debugging it?
__________________
Save the whales, feed the hungry, free the mallocs!
 
Posts: 946 | Thanked: 1,650 times | Joined on Oct 2009 @ Germany
#6
which qemu version are you using?
You could try to get wine running on a x86 host (x86 on qemu on x86) first.
 
Posts: 173 | Thanked: 160 times | Joined on Jan 2010 @ London, UK
#7
With the following

mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
echo ':i386:M::\x7fELF\x01\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x02\x00\x03:\xff\xff\xff\xff\xff\x fe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff \xff:/home/user/qemu-i386:' >/proc/sys/fs/binfmt_misc/register
echo LD_LIBRARY_PATH=/opt/root/x
~/wine/usr/lib/wine $ file /lib/ld-l*
~/wine/usr/lib/wine $ file -L /lib/ld-l*
/lib/ld-linux.so.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
/lib/ld-linux.so.3: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), stripped
~/wine/usr/lib/wine $

I can simply run arm or x86 linux binaries with reasonable success. fork/clone don't work so wine can't run stuff but will execute:

~/wine/usr/lib/wine $ /usr/bin/file /usr/bin/file
/usr/bin/file: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), stripped
~/wine/usr/lib/wine $ file ../../bin/wine
../../bin/wine: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.18, dynamically linked (uses shared libs), stripped
~/wine/usr/lib/wine $ wine
qemu: Unsupported syscall: 240
Usage: wine PROGRAM [ARGUMENTS...] Run the specified program
wine --help Display this help and exit
wine --version Output version information and exit
~/wine/usr/lib/wine $ wine --version
qemu: Unsupported syscall: 240
wine-1.1.29
 

The Following User Says Thank You to damion For This Useful Post:
Posts: 2 | Thanked: 3 times | Joined on Jan 2010 @ France
#8
There are two things here :

- The unsupported syscall 240 is __NR_futex. The problem is that QEMU doesn't support NPTL for x86. This will certainly cause some problems with clone.

- You shouldn't mix host and guest files in the same place! Copy an x86 filesystem somewhere, and chroot into it from inside QEMU. That's the safest way of doing things
 

The Following 2 Users Say Thank You to ldesnogu For This Useful Post:
2disbetter's Avatar
Posts: 365 | Thanked: 98 times | Joined on Nov 2009
#9
I'm following this thread with much interest. Please keep us updated on your attempts.

2d
 
Posts: 173 | Thanked: 160 times | Joined on Jan 2010 @ London, UK
#10
Originally Posted by ldesnogu View Post
There are two things here :

- The unsupported syscall 240 is __NR_futex. The problem is that QEMU doesn't support NPTL for x86. This will certainly cause some problems with clone.

- You shouldn't mix host and guest files in the same place! Copy an x86 filesystem somewhere, and chroot into it from inside QEMU. That's the safest way of doing things
Thanks, I've also (yesterday) heard the same about NPTL from the qemu developers list. Simply my use of particular userland libs could be causing me the issues. I might try and find quite old dists to compile against or just nick binaries from.

As for mixing stuff, well I was segregating with ./ld-linux.so.3 --library-path ... ./binary which is not quite chrooted but as separate as safe. But mixing was cool and I know the dangers I've also been unable to get chroot (busybox) to work as I expected it, I get /bin/sh no such file or directory despite there being a bin/sh in the /place/ I'm chrooting to.

Sadly I'm away for 3 weeks now with probably limited connectivity. I encourage others to try what I've checked out. Qemu peeps say my override of __clear_cache() was okay, so the qemu-i386 binary is safe to use, if somebody wants a copy it's wgetable from this url: http://a.trap.me.uk/qemu-i386 - they also agree a p90 was reasonable speed to expect (excluding any floating point). My experience with xeyes and topper show that graphically it's nifty and well worth investigating.

The rest of this thread should help the rest of the set up, most people will have the right libs and files lying around.
 

The Following User Says Thank You to damion For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 09:58.