blob: 0568b03f65095492e440cd585f81353b5b4e76c2 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
<think>
Okay, I'm trying to figure out how to classify this bug report about QEMU. The issue mentions that the `syscall.c` file lacks the `pselect6_time64` function. In commit 50efc6958638..., they removed the legacy `pselect6` definition for riscv32 and switched to using `pselect6_time64`. However, it seems that `pselect6_time64` isn't present in `syscall.c`, which means the riscv32 architecture is missing the `pselect` syscall.
So I need to categorize this bug into one of three categories: instruction, syscall, or runtime.
The problem here is specifically about a system call (`pselect`) not being correctly implemented due to a missing function in the codebase. The user points out that `pselect6_time64` isn't available, which affects the availability of `pselect` on riscv32 systems. This directly relates to how system calls are handled in QEMU.
Looking at the categories:
- Instruction: Relates to processor instructions or assembly code issues.
- Syscall: Involves problems with system calls and their handling.
- Runtime: Other runtime errors not covered by the above.
Since this is about a missing system call implementation, it falls under the 'syscall' category. The issue isn't about an instruction error or a runtime crash but rather the absence of a necessary syscall definition leading to functionality issues on riscv32.
</think>
The bug report discusses the absence of a specific system call (`pselect6_time64`) in QEMU's `syscall.c` file, causing the `pselect` syscall to be unavailable for riscv32. This is an issue with how system calls are handled.
**Answer:**
syscall
|