blob: 0b6475233a2d717b72af9d8a1d0455b1356e0d1c (
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 report falls into. The user mentioned that when they run QEMU in user mode for ARM, they're encountering unsupported syscalls 370 and 355. These issues are causing problems with systemd or a similar package.
First, I'll break down the information given. The error messages clearly state "Unsupported syscall: 370" and "Unsupported syscall: 355". Syscalls are system calls made by userland programs to the kernel, so when QEMU reports these as unsupported, it suggests that QEMU doesn't have implementations for these particular syscalls in its ARM emulation.
Looking at the possible categories provided: instruction, syscall, runtime. The problem here isn't about a faulty instruction or something wrong during runtime execution; it's specifically about missing system call handlers. So this seems directly related to syscalls not being supported in QEMU's user mode for ARM.
I think the category should be 'syscall' because the issue revolves around the inability of QEMU to handle certain syscalls required by the system (like systemd) when running in an ARM environment. The errors are not about incorrect instructions or runtime exceptions but rather missing support for specific syscalls.
</think>
The bug report involves QEMU failing to support certain system calls, specifically 370 and 355, which are necessary for proper operation of the system under emulation.
syscall
|