linux-user: Unable to run ARM binaries on Aarch64

[Philippe Mathieu-Daudé]

Download a ARM package from https://packages.debian.org/sid/busybox-static

Here tested with: busybox-static_1.30.1-4_armel.deb

$ file busybox.armel
busybox.armel: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=12cf572e016bafa240e113b57b3641e94b837f37, stripped

$ qemu-aarch64 --version
qemu-aarch64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14)

$ qemu-aarch64 busybox.armel
busybox.armel: Invalid ELF image for this architecture

$ qemu-aarch64 -cpu cortex-a7 busybox.armel
unable to find CPU model 'cortex-a7'

Also reproduced with commit 33d609990621dea6c7d056c86f707b8811320ac1,
while the aarch64_cpus[] array contains Aarch64 CPUs, the arm_cpus[] array is empty:

$ gdb -q aarch64-linux-user/qemu-aarch64
(gdb) p aarch64_cpus
$1 = {{name = 0x1fe4e8 "cortex-a57", initfn = 0x109bc0 <aarch64_a57_initfn>, class_init = 0x0}, {name = 0x1fe508 "cortex-a53", initfn = 0x109a10 <aarch64_a53_initfn>, class_init = 0x0}, {name = 0x1fe518 "cortex-a72",
    initfn = 0x109868 <aarch64_a72_initfn>, class_init = 0x0}, {name = 0x218020 "max", initfn = 0x109d70 <aarch64_max_initfn>, class_init = 0x0}, {name = 0x0, initfn = 0x0, class_init = 0x0}}
(gdb) p arm_cpus
$2 = {{name = 0x0, initfn = 0x0, class_init = 0x0}}

[Richard Henderson (rth)]

Of course. There's a separate qemu-arm executable for that.

[Laurent Vivier (laurent-vivier)]

Le 25/06/2019 à 16:43, Richard Henderson a écrit :
> Of course. There's a separate qemu-arm executable for that.

On some other architectures (like ppc/ppc64) the idea is the 64bit
version supports also all 32bit versions CPUs.

I think it's why this bug has been opened.

[Philippe Mathieu-Daudé (philmd)]

On 6/25/19 5:27 PM, Laurent Vivier wrote:
> Le 25/06/2019 à 16:43, Richard Henderson a écrit :
>> Of course. There's a separate qemu-arm executable for that.
>
> On some other architectures (like ppc/ppc64) the idea is the 64bit
> version supports also all 32bit versions CPUs.
>
> I think it's why this bug has been opened.

At any rate the error message could be more explicit, to avoid confusion.