blob: f7079e122b6e5167921585a7d3ec23573db1450b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I need to figure out whether this bug in qemu-aarch64-static is user-mode or system-mode related. Let's look at the information provided.
The issue occurs when using dh_fixperms, which runs a find and xargs chmod. That sounds like it's happening during package installation or build processes, so maybe within the user space of an application.
Then there's debootstrap --second-stage, which is used to set up a chroot environment for arm64 on a non-native host. It's invoking shell scripts like postinst, which are part of Debian packages and typically run in the user mode context.
Looking at the stack trace from gdb, the crash happens in memcpy while handling signal processing. The function calls go through target_setup_sigframe, setup_frame, process_pending_signals, and cpu_loop in main.c. These functions seem to be dealing with signals and CPU loops within QEMU's user-mode emulation.
The problem was fixed by sigprocmask wrapper patches from SUSE's tree. Since these are wrappers related to signal handling in the user space, it points towards user-mode issues where QEMU is emulating a target architecture's userspace processes.
Qemu-system typically runs as system-mode, dealing with hardware and full OS emulation, but qemu-aarch64-static is a user-mode binary meant for executing ARM64 binaries on an x86 host. The crash during signal handling aligns more with the user-mode context rather than managing devices or peripherals in system-mode.
So putting it all together, this bug is related to user-mode emulation within QEMU.
</think>
user
|