Software breakpoints get hit twice if the ISR executed directly after the breakpoint instruction

[bigfarts]

I'm not sure if this is an mGBA issue or an issue in MEGA_EXE3_BLA3XE, but sometimes, if the ISR is triggered after a software breakpoint, it can return control to the same PC and re-execute the same instruction, causing the breakpoint handler to execute twice.

See this Gist for tracing: https://gist.github.com/bigfarts/edc75b8c207cbf76c98e336cfa2948ef

To reproduce this, enter a battle using the patched MEGA_EXE3_BLA3XE ROM (replace 0x0000643E with EF BE, should be 04 1C originally) and sometimes you can get this trace where ThumbStep will run 0x0000643E twice:

trace ThumbStep: pc = 08006440, lr = 08008829, opcode = beef
trace ThumbStep: pc = 03005f2e, lr = 03005f00, opcode = 4770
trace ThumbStep: pc = 08006440, lr = 08008829, opcode = beef
trace ThumbStep: pc = 08006440, lr = 08008829, opcode = 1c04
trace end

Weirdly enough though, this doesn't seem to happen in BN4, 5, or 6.

[bigfarts]

The interrupt in question being fired looks like it's hblank, which isn't enabled in BN456 which explains why I haven't seen it there.

I'm not 100% sure on this (this doesn't explain why the instruction gets double executed) but here is my working theory:

• Software breakpoint is triggered, entering the breakpoint handler and ARMRunFake replaces the CPU prefetch,
• If the software breakpoint causes cycles to exceed the cycles for the next event, the hblank ISR routine is entered and the PC + prefetch are clobbered,
• When we return, we never see the effects of the ARMRunFake in the breakpoint handler since the ISR ate it.

[bigfarts]

I've managed to somewhat work around this issue by issuing a step in the breakpoint handler:

1. bkpt16 IRQ handler is entered,
2. set prefetch with ARMRunFake,
3. breakpoint handler is called (pc may be moved in the handler, so ARMRunFake is called before the handler is called),
4. core->step is called to run the next instruction directly without being interrupted by the ISR (processEvents is not called)

I don't know if this is correct, but it seems to do the right thing!