blob: 7a56a85070aa01e3394eb994c3978bc94b5b1213 (
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 bug is related to user-mode or system-mode. Let me start by understanding the problem.
The user is building QEMU on an ARM machine to run x86_64 executables in user mode. They've configured QEMU with --disable-system and --disable-tools, which suggests they're only interested in running user-space applications without a full OS simulation.
They provided a test program that uses GLib, which relies on certain system calls. When they run the 32-bit version using qemu-i386, it works fine, but when using qemu-x86_64 for the 64-bit target, it crashes with a segmentation fault. The strace log shows that the error is happening during a sys_futex call.
Futex (Fast User-space MUTEx) is a Linux system call used for user-space synchronization primitives. So, if QEMU isn't handling this correctly in x86_64 mode, that's likely a user-mode issue because futex is part of the user-space API and not related to system-level operations like device drivers or kernel functions.
The fact that the 32-bit version works but the 64-bit doesn't points towards something specific in how QEMU emulates x86_64 syscalls. Since they're only running user applications, it's more about correctly translating and handling user-space syscalls rather than system-level operations.
So, this seems to be a problem within the user-mode emulation of QEMU for x86_64 targets. The failure in futex suggests an issue with how that particular syscall is being handled or translated by QEMU when running 64-bit executables.
</think>
user
|