TODO: see if there's any other debug-string-output functions that we can
pass to debugger?
Might be worth adding a custom GDB command for toggling these too, some
games could be spammy
Register changes won't always register if context promotion pass is enabled,
fortunately this was noted by benvanik at
3d30b2eec3/src/xenia/debug/ui/debug_window.cc (L1004)
Disabling context promotion pass if --debug is set seems to allow register
updates fine, without too much performance loss on my end.
Still need to implement PC and CR reg writes, and the WriteRegistersAll cmd
Not completely sure if all register writes actually take effect yet, seems
GPR are fine at least but unsure about others
Detach will clear breakpoints and resume execution
Reconnecting should now work fine, could probably have multiple connections
too (may be some threading issues with that though...)
- Update OnThreadBreakpointHit to use bp->ContainsHostAddress
Sometimes guest PC doesn't map to the x64 exactly, so ResolveStack may return
a guest PC different to the breakpoint that triggered it
Processor code would just skip the breakpoint entirely if PC didn't match
so any debugger wouldn't know what BP caused it
Luckily BP does have a ContainsHostAddress func which seems perfect, but was
somehow left unused
Also added a hack to nudge the PC we tell GDB about to the BP's PC
- Update StepGuest/HostInstruction to add step BP to front of map
Fixes an issue where a different BP might get triggered before the step BP
which could cause debugger to step again, causing assert error as a step BP
already existed
I noticed one more issue, if BPs are set on instructions very close together
it might act on the same x64 instruction, causing assert when a BP is already
placed and another BP tries to set on the same addr...
Not really sure what best way to fix that is yet, for now just don't place
BPs too close together!
Fixed issue in processor.cc which prevented resuming from a breakpoint
BPs would set 2 bytes of the x64 JIT opcode to an invalid opcode & then catch
the exception from it - BP handler then restored the original opcode, but
then advanced RIP by 2 bytes into that opcode for some reason?
It would also suspend the thread just prior to this RIP change,
causing some strange effects... moving suspend after it (and removing the
offset) appears to work fine, though I didn't test the imgui debugger yet
To use GDBStub run xenia with "--debug --gdbport 12345" args
Tested with IDA 9 + idaxex loader, BPs can be set and resumed fine, suspend
& resume also works - memory/registers are viewable but can't be changed yet
The socket code here is very basic and only allows a single connection for
the session, if you disconnect you'll need to restart emulator
emoose