Peter Maydell <[email protected]> writes: > On Mon, 6 Jul 2026 at 11:33, Alex Bennée <[email protected]> wrote: >> >> Peter Maydell <[email protected]> writes: >> >> > On Sun, 5 Jul 2026 at 23:44, Gilles Grimaud >> > <[email protected]> wrote: >> >> >> >> While working on Raspberry Pi Pico/RP2040 support, I noticed that Pico SDK >> >> programs deliberately execute BKPT from _exit(). On real hardware this is >> >> useful when a debug probe is attached: returning from main() stops the >> >> debugger at the program exit point. >> >> >> >> Under QEMU this currently does not behave like the debug-probe case. For >> >> M-profile guests, the BKPT instruction is routed through the architectural >> >> guest debug exception path. Without halting debug, that path should >> >> remain a >> >> guest-visible DebugMonitor exception when DebugMonitor is enabled, or >> >> escalate >> >> towards HardFault otherwise. This patch deliberately leaves that >> >> no-debugger >> >> architectural path unchanged. >> >> >> >> The problem addressed here is the case where GDB is connected to QEMU's >> >> gdbstub. In that situation, firmware that uses BKPT as a debugger stop >> >> point >> >> should stop in the attached debugger. Instead, the M-profile guest >> >> currently >> >> continues down the guest exception path and may end in HardFault/lockup >> >> rather >> >> than reporting a clean trap to GDB. >> >> >> >> This is not specific to the RP2040 machine model. It is a generic >> >> Cortex-M/gdbstub interaction: firmware that uses BKPT as a debugger stop >> >> point >> >> should be reported to the attached debugger, while keeping the guest >> >> architectural exception path when no debugger is attached. > >> > No other architecture, CPU or board in QEMU needs to do this, >> > so my instinct is to say that M-profile should not be special here. >> > Richard, Alex: how do we usually handle breakpoint insns for the >> > gdbstub ? >> >> For TCG guests we never insert BKPT instructions and treat the system as >> having infinite hardware breakpoints. > > This isn't about gdbstub-inserted breakpoints, it's about > what happens when the guest code has a breakpoint insn in it > already (either hardcoded, or also could happen if we're running > gdb inside the guest). That's something that can happen for any > CPU type.
So far nothing - there is a helper_debug in sparc which raises the internal EXCP_DEBUG exception but as far as I can tell it is never called. We could treat gdbstub as an external debug monitor but we don't currently model it as such. > > thanks > -- PMM -- Alex Bennée Virtualisation Tech Lead @ Linaro
