Wasm debugging MVP

[billti]

Per discussion on the last video call, opening an issue to discuss goals for an initial MVP of Wasm debugging. (And once the issue discussion starts converging, I'll open a PR to capture in a document in the repo).

Goals

• The interfaces for the “Wasm Debug Module” (hereon abbreviated as “WDM”) should be proposed on https://github.com/WebAssembly/debugging
• DWARF extension recommendations should proposed in https://github.com/WebAssembly/tool-conventions
• Recommendations for a subset of LLDB/GDB protocol support for the Wasm engine proposed in https://github.com/WebAssembly/tool-conventions
  • Note: Perhaps not necessary. But if V8 and Wasmtime end up using this “LLDB protocol” approach, consistency could make for interop between Wasm debuggers (and LLDB) & Wasm engines.
• Prototypes available for two different Wasm engines (either in accessible and buildable branches, or behind product flags) supporting the below scenarios:
  • Dependency: C++ and/or Rust code compiled to Wasm with DWARF symbols emitted using proposed DWARF extensions. (May require some post-processing).
  • Note: Expectation is this will be via the LLVM toolchain with a version of the DWARF patch already in progress, and following the above recommended DWARF extensions.
  • A WDM implementing the proposed interfaces and consuming the generated DWARF data for source information.
  • A debugger front-end (e.g. Chrome Dev Tools, Firefox Dev Tools, VS Code, etc.) that can load the WDM (maybe out-of-proc) to debug the target engine.
  • Note: It is expected implementations at this point will have some requirements and limitations, e.g. needing to launch the engine in "debug mode", suppressing certain optimizations, etc.
  • Recommended: The debugger should adapt the WDM commands emitted to control the debug target, to the recommended LLDB commands implemented by the Wasm engine.
  • The ability to:
  • Set & clear breakpoints by original source line or function name
    • Non-goal for MVP: Set conditional/expression break-points.
  • Navigate up/down the frames of the Wasm call-stack
  • Non-goal for MVP: Being able to navigate to a JavaScript frame while broken in Wasm, and vice-versa.
  • View the “mixed” call-stack (e.g. list the JavaScript and Wasm frames on the stack with function names/locations).
  • View the parameters and variables (including globals) that would be in scope at the current frame for the source language.
    • Non-goal for MVP: Being able to modify the values of the above bindings.
  • Support for debugger commands to step-into, step-over, step-out, and continue.
  • Break on trap when a debugger is attached.
  • View/modify bytes in the Wasm memory range.
  • Recommended: A "proof-of-concept" implementation for a non-DWARF based debugging scenario via a WDM (e.g. debugging .NET code in the Blazor VM inside Wasm, or similar).
  • Recommended: A "proof-of-concept" implementation for debugging a source language with very different semantics or syntax to C++ or Rust (e.g. Haskell, Python, etc.)

Not required for the MVP

The below are debatable. They are definitely valuable and needed eventually, but are they needed to prove out the design in an MVP?

• Debugging multiple Wasm threads
• Debugging with multiple Wasm modules (and thus Wasm Debug Modules) loaded.
• Toggling between debugging the original source, and debugging the underlying Wasm (i.e. via the WAT representation).

Please comment with your take on the above, and what should be added, removed, clarified, etc. (Or if the proposal should take a different form entirely).

[fitzgen]

I wonder if it makes sense to have MVPs per-deliverable rather than MVPs for the whole subgroup? That is, discussion about an MVP for debugging modules and an MVP for a DWARF+Wasm convention document don't seem like they will overlap a bunch.

• View the parameters and variables (including globals) that would be in scope at the current frame for the source language.

At an earlier subgroup meeting, it seemed like we had rough consensus that we should start with feature parity with source maps (whether this is a pre-mvp milestone or is the mvp is perhaps a matter of terminology). That is, we would initially aim for source-level stepping, breakpoints, and symbolication, and then after that do scopes/variables.

I was working with this assumption when I wrote up #6.

Do we still feel like this is a good first milestone / division of features?