1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
<think>
Okay, I'm trying to figure out whether this QEMU GDB issue is related to user-mode or system-mode. The problem occurs when debugging an armv7-m binary on QEMU using GDB. The user reported that the backtraces over signal handlers aren't handled correctly because GDB doesn't recognize the M-profile EXC_RETURN value.
From what I understand, in ARM architectures, there are different profiles like A, R, and M. Cortex-M processors use the M-profile, which has specific features that GDB needs to know about. The user mentioned that QEMU is providing the feature 'org.gnu.gdb.arm.core' instead of 'org.gnu.gdb.arm.m-profile', causing GDB to think it's an A/R profile target instead of M.
The reproduction steps involve running a QEMU instance with a specific board (lm3s6965evb) and kernel image. The GDB session shows that after hitting a breakpoint in the 'svc' function, the backtrace stops because it can't recognize the EXC_RETURN value correctly.
So, considering whether this is user-mode or system-mode related:
- User-mode typically deals with application-level debugging where each process runs in its own address space. GDB connects to a target and debugs without needing full OS support.
- System-mode relates more to low-level debugging, possibly involving kernel code, device drivers, or higher privilege levels.
In this case, the issue is about how QEMU exports the core registers XML description to GDB. This affects the ability of GDB to correctly interpret the target's state, particularly in handling exceptions and stack traces for M-profile cores. Since it's about low-level debugging features specific to a CPU architecture and not just an application running on top, this seems more like a system-mode issue.
Additionally, the problem arises during kernel-level debugging or at least when dealing with interrupt/exception returns, which are lower-level concerns. Therefore, it's likely a system-mode related bug.
</think>
system
|