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. thanks -- PMM
