> On 8. Jul 2026, at 11:31, Peter Maydell <[email protected]> wrote:
>
> On Tue, 7 Jul 2026 at 18:27, Richard Henderson
> <[email protected]> wrote:
>>
>> On 7/6/26 02:21, Peter Maydell wrote:
>>> 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 ?
>>
>> We handle them via CPUBreakpoint structures; we never inject code changes.
>
> I don't mean "breakpoints that the gdbstub requests", I mean
> "breakpoint insns that are already in the guest code that get
> executed".
>
>> The patch description explains the confusion: this is attempting to
>> replicate a feature of
>> the Raspberry Pi Pico SDK, wherein a guest BPKT really is trapped by an
>> external debugger.
>
> But aren't breakpoint instructions of all kinds typically trapped
> to the external jtag debugger, on any architecture ? I'm a bit
> surprised that we don't do this already.
Some context on the gdbstub implementation from the x86 side:
WHPX's gdbstub support is implemented with overriding the instruction
instead of leveraging HW breakpoints - although a bit hackily.
A big concern is still allowing self-hosted debug to work fine which
makes things a bit harder.
x86 makes things easier by having multiple different breakpoint instructions.
Linux uses int3 and we use int1* for QEMU gdbstub-controlled breakpoints so
that things (mostly) work out for everyone.
And then, QEMU traps all debug exceptions from the guest when gdb is attached
and is supposed to take action when it’s an int1 breakpoint and not others.
Although we currently have a bug there that the non int1s just get ignored
instead of being injected back.
* on x86, the Intel manual says "Hardware vendors may use the INT1 instruction
for hardware debug"
On Cortex-M self-hosted debug is far less used than for emulating bigger chips.
And then there’s emulating such a thing using hardware virt and using HW
breakpoints
which quickly becomes quite complicated...
