First version of DebuggingFramework.md.
@lukewagner @sunfishcode @yurydelendik @titzer @jfbastien PTAL
Thanks for writing this up! At a high-level, this matches my basic understanding of the idea.
Overall this looks like a good start.
This specifies the browser devtools as the UI that the user will be interacting with. Another idea which has been discussed is that debuggers could provide their own UI, perhaps in a frame. The proposal here has the advantage that it should be easier to develop simple debuggers, because debugger writers need not implement their own UI, as the browser devools UI will often be sufficient. However, some debuggers may still want their own UI, for example to provide greater source-language-specific customization. Would it be difficult to accommodate this option in this proposal?
@sunfishcode: agree that some debuggers will want to provide their own UI (eg, Brackets and IntelliJ, which already do so for JS). That requires exposing the debugger<>debuggee interface as a remote-client protocol. We'd probably want to standardize the protocol so the external debugger only need implement it once (and not once per supported browser). I guess the question is how hard is it to standardize the remote-debugging protocols of multiple browsers?
I'd love for there to be a low-level debugging API that is implemented by the WASM VM:
- A query to enumerate threads
- A query to get the current call stack from a thread: an array of frames, each frame containing the function (maybe as a module instance pointer + function index), bytecode offset, local variable and operand stack values (if known)
- Queries to get the value of non-exported module instance definitions: memories, tables, global and in the future thread-local variables
- Commands to pause/resume execution of a thread
- Commands to add/remove breakpoints: when execution reaches some bytecode address in a function, suspend the thread and enqueue a message to the debugger
- A command to register a message queue to receive notifications of breakpoints, traps, etc
The goal would be to factor source-level debugging out of the WASM VM, to allow it to be implemented in unprivileged code, and to allow the source-level debugging implementations to be portable between different WASM VM.