blob: e4c9dc931fccc907c85ce24b5d332326b2ba5208 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Alright, let me try to figure out whether this QEMU crash is a user-mode or system-mode issue. So, the problem occurs when using qemu-user-arm version 4.0.0-rc0 for crosscompilation purposes. The user mentions that it crashes with SIGILL on specific instructions.
First, I need to understand what's happening here. QEMU has two main modes: user mode and system mode. User mode is used for running individual programs without a full OS, typically for cross-compiling. System mode emulates an entire system, including hardware devices and the OS.
Looking at the details provided, the user is using qemu-arm with various options like -cpu max and specifying a rootfs. This suggests they're setting up a user-mode environment because they're targeting a specific CPU (max) and using a custom root filesystem for cross-compilation.
The crash occurs when executing ARM NEON instructions (vseleq.f64 and vrintm.f64). These are floating-point operations, so perhaps there's an issue with how these instructions are being handled in QEMU 4.0.0-rc0 compared to the older version they're using (3.1.0), which works fine.
Since the problem arises when running binaries under user-mode emulation and not when emulating a full system, it points towards a user-mode issue. The fact that it's about crosscompilation further supports this because user-mode is often used for such tasks without needing a full OS setup.
I don't see any mention of hardware devices or peripherals failing, which would be more indicative of a system-mode problem. Instead, the focus is on specific CPU instructions and binary execution, which are core to user-mode functionality.
So, putting it all together: the crash happens in user-mode emulation when running binaries that use certain ARM NEON instructions. This is a regression from an older QEMU version, so it's likely a bug within the user-mode component of QEMU.
</think>
user
|