blob: d86eee47ee693b2b5242706f7651a4693ab258b3 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Alright, so I'm trying to figure out whether this bug report is related to user-mode or system-mode in QEMU. Let's break down the information provided.
The user mentions they're unable to run an ARM binary on AArch64 using QEMU. They've downloaded a busybox-static package for armel (which is 32-bit ARM) and tried running it with qemu-aarch64. The error messages indicate that the ELF image isn't valid for this architecture, even after specifying a CPU model like 'cortex-a7', which QEMU couldn't find.
Looking into the GDB output, they checked two arrays: aarch64_cpus and arm_cpus. The aarch64_cpus array has several entries with different Cortex models, but the arm_cpus array is empty. This suggests that QEMU doesn't have any ARM CPUs defined in user-mode for 32-bit execution.
The issue here seems to be about running a user-space program (busybox) on an AArch64 system using QEMU's user-mode emulation. Since it's about executing binaries and CPU models, it falls under the user-mode category. User-mode deals with running applications without emulating the entire OS or hardware peripherals.
Additionally, the fact that arm_cpus is empty indicates a problem in setting up the necessary 32-bit ARM CPUs for user-mode execution within QEMU. This isn't related to system-level emulation which would involve things like device drivers, higher privileges, or full OS booting.
</think>
user
|