1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I'm trying to figure out whether this QEMU regression is a user-mode or system-mode issue. The user reported that when they upgraded from qemu-armeb version 2.7 to 2.8 (and it's still present in 2.10.1), their GCC validation tests started failing with test cases involving atomics, specifically atomic-exchange-4.exe.
So, the problem occurs during the execution of a program that uses atomic operations. The error message shows an uncaught target signal 6 (Aborted), which usually indicates an abort due to some condition like invalid memory access or other fatal errors.
Looking at the provided details, when they run with version 2.7, it works fine (exit code 0), but with 2.8 and later, it crashes with exit code 134 (which is 128 + 6, corresponding to signal 6). The disassembly shows a difference in the instruction execution path at startup.
The key here is that they're running user-mode emulation because they're executing an executable file directly with QEMU using the -cpu any option. This suggests it's not a full system (like booting an OS) but rather just running the application in a simulated environment, which aligns with user-mode.
In user-mode, QEMU emulates the CPU and handles system calls by translating them to the host's system calls. The crash is happening during program execution, specifically when handling atomic operations. This likely points to issues within how QEMU translates or executes certain instructions related to atomics in user-space programs.
Since the problem arises from running a specific application and not from system-level components like devices, peripherals, or higher-privilege operations, it's more about how QEMU handles user-space code execution rather than managing virtualized hardware or an operating system kernel. Therefore, this issue is related to user-mode.
</think>
user
|