blob: 2fee5082dff78d1f062feefedad41e6e421a7e66 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
<think>
Alright, so I need to figure out whether this pthread_cancel issue in QEMU is a user-mode or system-mode problem. Let's break down the information given.
The user provided a minimal example where using pthread_cancel causes the program to fail with exit code 161 when run on an Alpine Linux aarch64 chroot. When using QEMU, it results in different signals but still crashes. The binaries were built with musl libc both dynamically and statically, which seems to be the common factor causing issues.
Looking at the test results table:
- When the binary is built against glibc (both dynamic and static), everything works fine whether run on the host or QEMU.
- The problems occur only when the binary is built against musl libc. Whether linked dynamically or statically, running it under QEMU causes a crash with either RT33 or Real-time signal 2.
From this, I can infer that the issue lies in how QEMU interacts with the musl libc implementation, particularly in user-mode emulation since the problem doesn't occur when using glibc. System-mode issues usually involve hardware-level interactions like peripherals or devices, which don't seem relevant here as it's about thread cancellation within a process.
The fact that both dynamic and static linking with musl cause the same issue suggests it's related to QEMU's user-mode environment not handling certain libc functions correctly when they're from musl. This would mean the problem is in how QEMU emulates the system calls or interacts with the threading model provided by musl.
So, considering that the issue arises within the user space and involves thread cancellation which is a user-level function, this points towards it being a user-mode problem.
</think>
user
|