Running headless with -dofile, breakpoints set via PCSX.addBreakpoint never fire. addBreakpoint returns a valid object and raises no error, but the callback is never invoked — verified both on the game's per-frame loop and on the BIOS reset vector at 0xBFC00000, which unquestionably executes. PCSX.nextTick also never fires in this mode.
The same applies to the GDB stub. Z0–Z4 all reply OK, but no breakpoint or watchpoint ever triggers. Notably qSupported advertises PacketSize, qXfer:* and QStartNoAckMode — but neither swbreak+ nor hwbreak+.
Adding -debugger fixes both immediately: Lua callbacks fire, and GDB watchpoints trigger correctly.
This is reasonable behaviour, but it's undiscoverable. The CLI docs describe -debugger as "Activates the debugger" without indicating that breakpoints are inert without it, and a stub answering OK to Z packets it then ignores is hard to distinguish from a target where the breakpoint simply hasn't been hit yet.
Suggestions, in rough order of value:
- Mention the
-debugger dependency in the Lua and CLI docs
- Have the GDB stub return an empty reply (the RSP convention for "unsupported") for
Z packets when the debugger is inactive
- Optionally log a warning when
addBreakpoint is called with the debugger off
One caveat for completeness: I did not test whether Lua breakpoints work with -debugger in headless mode specifically — I confirmed GDB watchpoints do and moved on. The qSupported observation and the docs gap stand regardless.
Version: nightly build 360 (24892.20260724.3, x64), Windows, interpreter core.
Running headless with
-dofile, breakpoints set viaPCSX.addBreakpointnever fire.addBreakpointreturns a valid object and raises no error, but the callback is never invoked — verified both on the game's per-frame loop and on the BIOS reset vector at0xBFC00000, which unquestionably executes.PCSX.nextTickalso never fires in this mode.The same applies to the GDB stub.
Z0–Z4all replyOK, but no breakpoint or watchpoint ever triggers. NotablyqSupportedadvertisesPacketSize,qXfer:*andQStartNoAckMode— but neitherswbreak+norhwbreak+.Adding
-debuggerfixes both immediately: Lua callbacks fire, and GDB watchpoints trigger correctly.This is reasonable behaviour, but it's undiscoverable. The CLI docs describe
-debuggeras "Activates the debugger" without indicating that breakpoints are inert without it, and a stub answeringOKtoZpackets it then ignores is hard to distinguish from a target where the breakpoint simply hasn't been hit yet.Suggestions, in rough order of value:
-debuggerdependency in the Lua and CLI docsZpackets when the debugger is inactiveaddBreakpointis called with the debugger offOne caveat for completeness: I did not test whether Lua breakpoints work with
-debuggerin headless mode specifically — I confirmed GDB watchpoints do and moved on. TheqSupportedobservation and the docs gap stand regardless.Version: nightly build 360 (24892.20260724.3, x64), Windows, interpreter core.