First version of DebuggingFramework.md.

[dekimir]

@lukewagner @sunfishcode @yurydelendik @titzer @jfbastien PTAL

[lukewagner]

Thanks for writing this up! At a high-level, this matches my basic understanding of the idea.

[lukewagner]

Nice chart! I'd put the "Debugger" box inside the browser box since it's executing JS or wasm code.

[dekimir]

I felt that the wasm module and the debugger should be shown outside, because they don't come with the browser but are downloaded. Then I try to explain in the text how they are used by the browser when obtained.

[jfbastien]

IIUC 4. and 5. are what you're specifying here, right? It sounds like @lukewagner wants to drop 3. from the diagram, but you'd rather keep it because it can be separate (not being specified in this doc)?

[dekimir]

Actually, this aims to specify 3 and 5, while leaving 4 unspecified (other than saying how the debugger can find the debug info and source files). The way the debugger interprets the debug info will be hidden from other actors in this picture, freeing the debugger implementers to choose whatever suits them.

[lukewagner]

I see your point and just noticed that "wasm module" is also, symmetrically, outside the box.

[sunfishcode]

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?

[dekimir]

@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?

[jfbastien]

That's a bit redundant, given that we're in the design repo ;-)

[AndrewScheidecker]

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.