So far only basic debugging functionality is implemented (breakpoints,
stepping, stack traces/variables).
This is not tested against an established DAP client. My intention is to
create a custom GUI frontend and extend the protocol to support
xsystem4-specific features, such as inspecting the scene. (This work is
underway.)
Instruction references are hex-encoded address strings. Clients do not
need to obtain them from DAP requests. This is outside the spec, but it
is needed for a binary-only debugger.
Functions that write directly to stdout (e.g. printf) should generally
not be used any more. Instead, use either sys_message (which respects
sys_silent) or log_message (which will send the message to the debugger
if DAP is enabled). stderr can be used as normal.
Add 'step' (s) and 'next' (n) commands for single-stepping bytecode.
'step' is the 'step into' type which descends into function calls,
wheras 'next' is the 'step over' type which continues until the next
instruction within the current function.
Read .xsys4-debugrc from ~/.xsystem4 and/or the game directory on
startup. This is just a text file with one debugger command per line.
Can be used to set breakpoints or log functions automatically at
startup.
This can also be used to work around a limitation on Windows where the
IME doesn't work in the debugger, making it impossible to input Japanese
text.
Add vm-state command, which prints disassembly around the current
instruction pointer and the current contents of the stack.
It was necessary to change how breakpoints are implemented for this.
When adding a breakpoint, the original opcode now remains in the
instruction stream, bitwise-or'd with BREAKPOINT. A hash table indexed
by address is used to store breakpoint objects.
* Add "frame" command to change the current frame.
* Add "members" command to print struct members for current frame (if it's
a method frame).
* Support printing member variables (e.g. "this.var") in the "print"
command.
Add a new debugger interface using a simple command language. This is
less powerful than the scheme interface (which still exists) but more
ergonomic for interactive debugging.
This debugger has no external dependencies (it will however use readline
if available) and is included in builds by default.
A sample interaction might look like:
xsystem4 --debug /path/to/game
dbg(cmd)> breakpoint bar
Set breakpoint at function 'bar' (0x00001234)
dbg(cmd)> continue
Hit breakpoint at function 'bar' (0x00001234)
dbg(cmd)> backtrace
#0 0x00001234 in bar
#1 0x00002222 in foo
#2 0x00004444 in main
dbg(cmd)> locals
[0] i: 2
[1] s: "baz"
dbg(cmd)> locals 1
[0] j: 3
[1] obj: { m_i = 0; m_s = "" }
dbg(cmd)> quit
This is implemented by inserting special opcodes into the game's code.
When the breakpoint handler is finished, it returns the original opcode
so that execute_instruction can continue executing normally.
E.g.
* start xsystem4 with --debug option to drop into debugger immediately
* run (bp "game_main")
* ^d or \exit to close debugger REPL
* ...drop into a debugger REPL again at the game_main function
- Create separate directories for source and header files.
- Build code shared between xsystem4 and aindump as a static library.
- Create header dirs gfx/ system4/ and vm/
- Make CG.c/h usable without a running VM
Nunuhara Cabbage