blob: d8e45a973298a53a3249ac5075c2344fb75cd7a9 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Alright, I'm trying to classify this bug report as either user-mode or system-mode related. Let me go through the details.
The problem occurs when using QEMU in conjunction with GDB. The issue is about breakpoints being ignored under certain memory page conditions. Specifically, a function starts at 0x10bff2 and the breakpoint is set at 0x10c00e, which is on another page. When running with `qemu -d in_asm,exec`, the function executes without hitting the breakpoint. However, setting another breakpoint earlier within the same page allows the later breakpoint to be triggered.
I know that user-mode emulation in QEMU deals with running applications (userland processes) under different architectures or for debugging purposes. Since the problem involves GDB breakpoints and instruction-level execution, it seems related to how QEMU's user-mode handles breakpoints across memory pages.
System-mode would involve lower-level aspects like device drivers, hardware emulations, or kernel operations, which doesn't seem to be the case here. The issue is about application code execution and debug points, so it fits more into the user-mode category.
</think>
The bug report involves GDB breakpoints in an application context, indicating a problem within QEMU's user-mode emulation.
user
|