blob: 82cc2388c9efb455a9ca3de5fac8cf4343c50197 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
|
<think>
Okay, let's see. The user is reporting an issue with QEMU's epoll functionality when running i386-linux-user on an ARM host, specifically between versions 2.5.1 and 2.6. They identified a commit that caused the problem and reverted it to fix epoll.
First, I need to classify this bug into one of the three categories: instruction, syscall, or runtime. The problem is related to epoll, which is a system call in Linux used for I/O event notification. The user mentioned that reverting a specific commit fixed the issue, which suggests that the commit introduced a change affecting how epoll is handled.
Since epoll involves system calls, I might think it's a syscall issue. However, the problem arises in the QEMU user-mode emulation, which translates host syscalls to target syscalls. If the commit altered how syscalls are intercepted or handled for the i386 target on an ARM host, that could be a syscall category issue. But the user says that reverting the commit fixed epoll, implying that the commit introduced a bug in the syscall handling specific to that setup.
Alternatively, runtime errors are other runtime issues not covered by instruction or syscall. But since epoll is directly tied to system calls, and the problem is with the syscall interface in QEMU's translation layer, this seems like a syscall category problem. The instruction category is for faulty CPU instructions, which doesn't fit here. So the correct category is syscall.
</think>
syscall
|