blob: dd5fbeccd167613ae768c8d460898c1869452685 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I'm trying to figure out whether this QEMU crash is a user-mode or system-mode issue. Let me read through the problem description carefully.
The user reports that `qemu-arm-static` crashes 100% of the time when running NEON code. They mention that using the same executable in system emulation mode works without issues. The crash happens inside JIT-generated code, and there's no memory access issue like SIGSEGV.
They provided some GDB output showing a segmentation fault at address `0x409e503c`. Looking at the disassembly around that address, it shows NEON instructions: vld1.8, vst1.8, and some adds and subs. The crash occurs when executing generated NEON code.
So, QEMU has two main modes: user-mode and system-mode. User-mode is for running binaries directly without a full OS, while system-mode emulates an entire system with hardware devices and so on.
In this case, the issue happens in user-mode because they're using `qemu-arm-static`, which is part of user-mode emulation. The problem seems to be related to how QEMU handles NEON instructions in JIT-compiled code when running in user mode. Since the same code works in system-mode, it suggests that the problem lies within the user-mode setup and not with the broader system emulation.
So, I think this is a user-mode issue because it's specifically about executing generated code in that environment.
</think>
user
|