Comment 6 for bug 739785

On 28 March 2011 21:13, moonman <email address hidden> wrote:
> Hello,
>
> [root@Plugbox ~]# strace -ff -o ls-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/ls
> b?   d?    e?            l?  mu-e386i  ome  oot  roc  s?  u?
> bin  diae  hlrc.tin.gar  m?  o?        oot  q    s?   t?  v?
>
> [root@Plugbox ~]# strace -ff -o bash-strace.log chroot /i386 /usr/bin/qemu-i386 /bin/bash -c /bin/ls
> /bin/bash: /bin/: %snnca eotcuxe btearinfiy

Something odd is going on here... Excerpts from the strace:

readlink("roc/self/f", 0x81abf80, 4095) = -1 ENOENT (No such file or directory)

open("/0):/usr/libalo/eNG=Sn_UF.UT!\304\27\10P\254\32\10\267\304\27\10\20/LC_IDENTIFICATION",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/0):/usr/libalo/eNG=Sn_UF.ut/LC_IDENTIFICATION",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/0):/usr/libalo/eNG=Sn_UF/LC_IDENTIFICATION",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/0):/usr/libalo/eNG=Sn.UT!\304\27\10P\254\32\10\267\304\27\10\20/LC_IDENTIFICATION",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/0):/usr/libalo/eNG=Sn.ut/LC_IDENTIFICATION",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/0):/usr/libalo/eNG=Sn/LC_IDENTIFICATION", O_RDONLY|O_LARGEFILE)
= -1 ENOENT (No such file or directory)
write(2, "/bin/bash: /bin/: %snnca eotcuxe"..., 47) = 47

That's clearly an attempt to open something in /proc/self, something
in /usr/lib/locale/, and to print a "cannot execute" message, but
everything's got rather twisted.

Swap every two pairs of bytes (or equivalently, rotate sets of four
characters by two) in this:
: %snnca eotcuxe
...and as if by magic, something comprehensible appears:
%s: cannot execu

Now, running x86 binaries on an ARM host does work for me, but I've
only tested on a Cortex-A8 (ARMv7) host. I think that what's happening
here is that qemu is doing unaligned accesses. On ARMv7 unaligned
accesses "work", ie you get the word you asked for. On ARMv5 the
effect is that the unaligned address is rounded down to a multiple of
four, we load 32 bits and then rotate them -- so you get the effects
you see above.

Short answer: looks like QEMU doesn't currently work on ARMv5 hosts
(although ARMv7 are fine). I'll look into this if I can manage to
scare up some suitable hardware.