1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, I need to classify this bug report into one of the given categories. Let's read through the problem description carefully.
The user is running a binary in QEMU and gets a core dump because of an uncaught target signal 5 (Trace/breakpoint trap). However, when using GDB for remote debugging, the program exits normally without any issues. This suggests that there's something different happening when QEMU handles signals compared to GDB.
Looking at the provided details, the binary uses the BKPT instruction in ARM assembly at address 0xa608. The user suspects that QEMU isn't correctly translating this BKPT instruction into a SIGTRAP signal, which is expected behavior for breakpoints.
They mention checking a previous bug (https://bugs.launchpad.net/qemu/+bug/1873898) and believe it's fixed, but the problem persists. The core dump occurs because QEMU isn't handling the BKPT correctly, leading to an uncaught signal. However, when using GDB, which presumably handles breakpoints differently, the program runs without issues.
Looking at the categories provided: mistranslation seems relevant here because it involves incorrect mapping from guest instructions (BKPT) to host signals (SIGTRAP). If QEMU isn't correctly translating BKPT into SIGTRAP, that falls under semantic mapping issues in user-mode translation.
Other categories like device or network don't seem applicable since the issue is with instruction handling, not hardware emulation. Similarly, it's not a graphics or socket-related problem.
Therefore, the bug is likely due to incorrect translation of guest instructions (BKPT) into host signals, which points to the "mistranslation" category.
</think>
The issue arises because QEMU isn't correctly translating the BKPT instruction into the SIGTRAP signal. This relates to how guest instructions are mapped in user-mode.
**Answer:**
mistranslation
|