blob: 5e2919b85e7308aad2d4bd032797314e70f0b31c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
<think>
Okay, I need to figure out whether this bug is user-mode or system-mode related in QEMU.
The user mentioned they upgraded to qemu-5.0 and started seeing random failures in the GCC testsuite, specifically g++.dg/ext/sync-4.C. The issue occurs when executing __aarch64_cas8_acq_rel, leading to a call to abort().
Looking at the provided code snippets:
- f13 is a function that uses __sync_bool_compare_and_swap on a pointer.
- t13 calls f13 with a null pointer and catches exceptions. If no exception is thrown, it calls abort().
The traces show execution starting from main, calling f13 which then invokes __aarch64_cas8_acq_rel. After returning, it goes to abort().
I recall that __sync_bool_compare_and_swap is a GCC built-in for atomic operations. On AArch64, this uses the CAS instruction, which might be handled by QEMU's user-mode emulation.
The problem arises during the execution of an atomic compare-and-swap operation, suggesting it's related to how QEMU emulates these instructions in user mode. Since the issue doesn't occur on native hardware but does in QEMU, it points towards a bug in QEMU's handling of AArch64 atomic operations.
System-mode issues usually involve higher privileges or devices, which isn't indicated here. The problem seems isolated to the execution of a specific instruction, pointing more towards user-mode emulation.
So, this is likely a user-mode issue because it's related to how QEMU handles certain instructions in user space rather than system-level components.
</think>
user
|