RFC notifications bot (Feb 21 2026 at 00:02): RFC notifications bot (Feb 21 2026 at 00:02):cfallin opened PR #45 from cfallin:wasmtime-debugging-v3 to bytecodealliance:main:
RFC notifications bot (Feb 26 2026 at 19:20):alexcrichton submitted PR review:
I'm likely a bit biased in having helped review much of the work so far, but nonetheless I personally feel that this strikes a good balance between flexible and usable and I feel this is a good way to move forward with. I'm hoping this can help pave the way forward (ish) for more and more parts of Wasmtime to be self-hosted wasm rather than built-in to the engine/API/etc.
We've still got a lot of details to figure out and bikeshed here, e.g. WITs, where the debugger wasms come from, CLI arguments, etc, but I'm confident we can find a good fit for all these (if not just take all the existing prototyping as-is). Overall I believe that expose-the-debugger-as-WIT is the right way forward at this time and then
wasi:cli/runon top provides a usable way to consume that.
RFC notifications bot (Feb 26 2026 at 20:49):fitzgen submitted PR review:
FWIW, I don't really think this is an "alternative" or "compromise" to the original debug adapter protocol; it is an incremental step and factoring of layers. You can use "debug main" to implement the original / long-term debug adapter components:
- component
$mainimports the Wasm-level debugging interface from Wasmtime$mainwraps an inner$debug-adaptercomponent that imports the Wasm-level debugging interface and exports a new source-level debugging interface$mainimplements a DAP server and translates incoming DAP source-level queries into invocations on$debug-adapter's exported source-level interface, which the$debug-adaptertranslates to invocations on the Wasm-level interface via DWARF or whatever other debug info it has, etc...So all that is to say that I think this is great! Love when we can path-find near-term wins that also acts as an incremental milestone towards the long-term end goal. Ship it!
RFC notifications bot (Feb 26 2026 at 21:10):Since we now have signoffs per
Once any stakeholder from a different group has signed off, the RFC will move into a 10 calendar day final comment period (FCP)
we are moving into the
Final Comment Period
and if no objections or other issues are raised, this RFC should merge on 2026-03-08.
RFC notifications bot (Feb 27 2026 at 11:52):tschneidereit submitted PR review:
I agree with Nick: this seems like an excellent step on the path to the original plan. What's more, I think it provides additional value in itself, so I think it's a really good addition!
RFC notifications bot (Feb 27 2026 at 22:34):JDevlieghere commented on PR #45:
I read through the RFC and wanted to express my excitements and support for the proposed approach. I think decoupling the two levels makes a lot of sense. As the person who's been working on this in LLDB, I'm obviously excited about the possibility of debugging Wasmtime over the GDB remote protocol.
As I've said in my FOSDEM talk, I am convinced that the GDB remote approach is the way to go for compiled languages like C, C++, Swift & Rust. However, I also agree that it would be a mistake for interpreted languages, where the Debug Adapter Protocol is a much better fit.
[...] it does not preclude building the DAP-based adapter ecosystem on top of the new world.
That's right, and that was the point I was trying to make in this discussion with @alexcrichton and @fitzgen. The RFC doesn't go as far as calling it out explicitly, but with the gdbserver + LLDB approach, you can leverage LLDB to do the heavy lifting and then use
lldb-dapto provide a DAP interface, like you would for interpreter languages.
RFC notifications bot (Feb 27 2026 at 22:35):JDevlieghere edited a comment on PR #45:
I read through the RFC and wanted to express my excitements and support for the proposed approach. I think decoupling the two levels makes a lot of sense. As the person who's been working on this in LLDB, I'm obviously excited about the possibility of debugging Wasmtime over the GDB remote protocol.
As I've said in my FOSDEM talk, I am convinced that the GDB remote approach is the way to go for compiled languages like C, C++, Swift & Rust. However, I also agree that it would be a mistake for interpreted languages, where the Debug Adapter Protocol is a much better fit.
[...] it does not preclude building the DAP-based adapter ecosystem on top of the new world.
That's right, and that was the point I was trying to make in this discussion with @alexcrichton and @fitzgen. The RFC doesn't go as far as calling it out explicitly, but with the gdbserver + LLDB approach, you can leverage LLDB to do the heavy lifting and then use
lldb-dapto provide a DAP interface, like you would for interpreter languages.
RFC notifications bot (Feb 28 2026 at 12:25):bnjbvr submitted PR review:
Looks great!
RFC notifications bot (Feb 28 2026 at 12:25):bnjbvr created PR review comment:
typo: endpoint
RFC notifications bot (Feb 28 2026 at 21:52):cfallin updated PR #45.
RFC notifications bot (Feb 28 2026 at 21:52):cfallin created PR review comment:
ah, fixed, thanks!
RFC notifications bot (Feb 28 2026 at 21:52):cfallin submitted PR review.
RFC notifications bot (Mar 09 2026 at 01:19):if no objections or other issues are raised, this RFC should merge on 2026-03-08.
It is now 2026-03-08 and no objections have been raised; therefore, I will merge this RFC!
I'll work on landing bits of my implementation of the debug-main world, and also a gdbstub component that works within it, this week.
RFC notifications bot (Mar 09 2026 at 01:19):cfallin merged PR #45.
RFC notifications bot (Mar 09 2026 at 01:19):cfallin edited PR #45:
Last updated: Mar 23 2026 at 16:19 UTC