1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Alright, so I'm looking at this problem where someone is running an a.out_err binary in QEMU's 32-bit ARM Linux-user mode and getting a core dump because of a signal 5 (Trace/breakpoint trap). They've noticed that when using GDB to remote-debug the program, it exits normally.
First, I need to understand what's causing this issue. The user provided some disassembly showing a BKPT instruction at address 0xa608. In ARM architecture, BKPT is used for breakpoints and should generate an exception. However, the user mentions that QEMU isn't correctly turning these guest BKPT instructions into a SIGTRAP signal in Linux-user mode.
Looking at the readelf output, it's an ELF32 executable for ARM with some specific flags. The entry point is at 0xa603, and the disassembly shows the BKPT instruction right after that. So when this binary runs under QEMU, it hits this breakpoint and expects a SIGTRAP to be sent, which would typically trigger GDB's debugger.
But in their case, instead of handling it properly, QEMU is causing a core dump. They've checked Launchpad bug 1873898, which seems related but they're still experiencing the problem, so maybe it hasn't been fully resolved or there's another issue at play.
The user wants to classify this bug as either 'user-mode' or 'system-mode'. User-mode issues typically involve processes running under QEMU without full system emulation, like using linux-user mode where each process runs in isolation. System-mode involves emulating a whole system with hardware devices and higher privilege levels.
Given that the problem occurs in the Linux-user mode of QEMU, which is for executing unprivileged user-space programs without full OS emulation, this points towards a user-mode issue. The problem isn't related to peripherals or device drivers but rather how QEMU handles signals within the guest process.
So, putting it all together, the bug is likely related to how QEMU's ARM Linux-user mode processes breakpoints and converts them into appropriate signals for debugging. Since it's happening in the context of a single user-space program without involving system-level components, this should be classified under 'user' mode.
</think>
The issue occurs within QEMU's user-mode execution environment where a guest BKPT instruction isn't correctly translated to a SIGTRAP signal, causing a core dump. This is related to how QEMU handles user-space processes.
user
|