qemu-stable
[Top][All Lists]
Advanced

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

Re: [PULL 5/5] linux-user: Fix qemu-arm to run static armhf binaries


From: Michael Tokarev
Subject: Re: [PULL 5/5] linux-user: Fix qemu-arm to run static armhf binaries
Date: Sat, 22 Jul 2023 10:37:33 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

22.07.2023 00:37, Helge Deller wrote:
..
So, this is kinda amusing.
This broke arm64, ppc64el and s390x:

arm64$ ./qemu-aarch64 /bin/sh -c '/bin/ls -dCFl *[t]* >/dev/null'
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

Note: I run it on native arm64, so it is arm64 on arm64, -
this is a quick test I had from the debian qemu autopkgtest (which
run /bin/ls under qemu and natively and compares the result).  I
haven't tried to reproduce it locally on amd64 host, - I did it on
a debian arm64 porterbox (which I was logged on anyway to debug a
different issue on armel, with qemu git tree already cloned).

Argh, that's really unfortunate.
I just tested myself.
Running static busybox binary did work for me:
# ./qemu-aarch64 busybox

It didn't trigger with ls, but it did when I run something from
emulated /bin/sh.

This whole email was more like a heads-up/warning, to collect more
details later, - and maybe someone knows what the problem is already
if it is obvious.

..
Maybe someone else can try? I leave it up to Peter if he wants to revert
that patch right now, or if it can wait a few days until I'm back?

For the time being, how about a quick-n-hacky band-aid, to include
this fixup only where the original prob actually triggered in the
first place?

Like, if the target is armel?  Something like

#if defined(TARGET_ARM) && !defined(TARGET_AARCH64)

or what's the right preprocessor condition is?

Thanks,

/mjt



reply via email to

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