1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, so I need to classify this bug report into one of the given categories. Let me read through the problem description carefully.
The issue is about QEMU reporting the wrong thread to GDB when an interruption (like Ctrl+C) occurs. Specifically, after resuming a thread using `vCont`, if another thread is interrupted by a signal like SIGINT, QEMU sends a stop reply with the ID of a thread that hasn't been resumed.
Looking at the categories provided: mistranslation, assembly, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor, and others.
The bug seems related to how QEMU handles thread state changes when interacting with GDB. The key points are:
1. GDB uses `vCont` exclusively for resuming threads.
2. When a thread is interrupted, QEMU calls `gdb_vm_state_change`, which constructs the stop reply based on `gdbserver_state.c_cpu`.
3. The `vCont` handler doesn't set `gdbserver_state.c_cpu` before resuming CPUs.
This indicates that there's an issue with how the state is being managed when handling thread interruptions and resume operations, specifically in the context of GDB communication.
Since this relates to debugging functionality and the interaction between QEMU and GDB, it falls under the 'debug' category. The problem isn't about translation errors or performance; it's more about correct event reporting during debugging sessions.
Therefore, the appropriate classification is 'debug'.
</think>
debug
|