blob: 9c4e877c94c99a233064ccf2c52d3316a43dc7eb (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm trying to figure out what category this bug falls into. The user reported that when they run QEMU via Flatpak for ARM images on an x86_64 system, they get an "Unknown syscall 397" error. They mentioned that statx is involved because of the syscall number.
First, I need to understand what's happening here. The user is using Flatpak to install and run KDE SDK and Platform for ARM on their x86_64 machine. When they try to run qmake inside the SDK, QEMU throws an error about an unknown system call. This causes issues where qmake can't find .pro files or libraries.
Looking at the categories provided: instruction, syscall, runtime. The user's problem is specifically about a syscall (number 397) that QEMU doesn't recognize. System calls are how user-space programs interact with the kernel. If the host system supports a syscall but QEMU doesn't emulate it properly for the target architecture, this error occurs.
Since the Flatpak images were built for AARCH64 hardware and they're running on x86_64, there might be compatibility issues. The host kernel (4.19.86) supports more syscalls than what QEMU is emulating for ARM. In this case, statx is a newer syscall that's not properly handled by the version of QEMU being used.
So, the bug isn't about an incorrect instruction or a runtime error in general. It's specifically because the system call isn't recognized by QEMU when translating it from AARCH64 to x86_64. This points directly to a syscall-related issue within QEMU.
</think>
syscall
|