blob: e146207ab7d5035e656a5eeff646562481c36d60 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, let's see. The user is reporting a bug in QEMU's user-space emulator. The problem is with the setsockopt syscall when the optlen is 0. Specifically, when the program calls setsockopt with NULL and 0 length, QEMU returns ENOMEM, but on real Linux it should return success.
First, I need to figure out which category this falls into. The options are instruction, syscall, or runtime.
The issue is definitely related to a syscall. The problem occurs when QEMU handles the setsockopt syscall. The user provided a test case that compiles a program using setsockopt with specific parameters. The problem isn't about incorrect instructions (like CPU instructions) but how the syscall is being intercepted and handled by QEMU's user-mode emulator.
The error is in the syscall handling logic within QEMU. When the optlen is zero, the real kernel would handle it, but QEMU's emulation is returning an error. This seems like a syscall handling bug. The runtime category is for other runtime errors, but since this is specifically about the syscall interception and handling, the correct category should be syscall.
So the answer should be "syscall".
</think>
syscall
|