Okay, I need to figure out how to classify this bug report about QEMU's handling of the BKPT instruction in arm linux-user mode. The user provided a detailed explanation and a test case where the arm version doesn't trigger SIGTRAP like the aarch64 does. First, looking at the problem: when running the arm binary under qemu-arm, it doesn't stop at the BKPT instruction as expected. Instead of sending SIGTRAP, it continues executing and prints "done". The issue seems to be in how QEMU handles the exception type EXCP_BKPT. The bug report explains that in cpu-loop.c for arm, EXCP_BKPT is treated similarly to EXCP_SWI. This means instead of delivering a trap signal, it's incorrectly handling it as a syscall or semihosting call. The user points out that this behavior was from an older commit and that the handling for semihosting has moved elsewhere, so now BKPT should be handled differently. The correct behavior is that BKPT should cause a SIGTRAP, like how EXCP_DEBUG does on aarch64. So the problem lies in how exceptions are processed in QEMU's arm code. Now, considering the categories: instruction, syscall, runtime. - Instruction: This relates to faulty instructions or incorrect handling of CPU instructions. - Syscall: Issues with system calls. - Runtime: Other runtime errors not covered by the above. In this case, the issue is about how an instruction (BKPT) is handled. The code treats BKPT as a syscall when it shouldn't. It's more about the correct processing of an exception caused by a specific instruction. So, it falls under "instruction". I think the category should be 'instruction' because it's about how QEMU handles a particular CPU instruction leading to incorrect exception handling. instruction