Stream: git-wasmtime

Topic: wasmtime / issue #12776 Debugging: implement debug compon...

Wasmtime GitHub notifications bot (Mar 13 2026 at 20:24):

cfallin opened issue #12776:

After #12771, we have wasmtime run -g <PORT> and wasmtime run -Ddebugger=<COMPONENT>, providing a good debugging experience for WASI-CLI programs.

We should build the top-level plumbing to allow attaching debug components, both custom ones and the built-in gdbstub one, to wasmtime serve request handlers as well.

The challenge that occurs in this environment is that there is not just one program lifetime, but a Store lifetime per HTTP request (modulo instance reuse). Both the gdbstub protocol, and the underlying debug-main environment, are oriented around debugging one program execution from start to finish.

There are two general approaches I can imagine:

• Treat each HTTP request as a program execution. This would spawn an instance of the debug component alongside the instance of the wasi-http component. That debug component could listen for a gdbstub connection before continuing, like wasmtime run today. When the one request is done, LLDB sees this as "process exited".
• Somehow stitch together all HTTP requests into one "virtual program execution" from the point of view of the debugger WIT API. In practice this would mean persisting some state (which breakpoints are set, for example). It would also imply building an invalidation mechanism for all Instance/Module/Table/Global/Func/... handles at the debug API level.
• Lean into instance reuse, and only have one long-running wasi-http component when we have debugging enabled.

The top-level user experience we probably want is something like: attach LLDB; set a breakpoint somewhere in a handler in a wasi-http component; get control and step through code after sending an HTTP request.

Option 1 is thus a terrible user-experience that we want to reject, I think. Either option 2 or option 3 could provide this desired experience. I favor option 3 for simplicity, in the sense that it bends the conceptual model the least, but I'm curious what others think as well!

Wasmtime GitHub notifications bot (Mar 13 2026 at 20:24):

cfallin added the wasmtime:debugging label to Issue #12776.

Wasmtime GitHub notifications bot (Mar 13 2026 at 20:38):

cfallin edited issue #12776:

After #12771, we have wasmtime run -g <PORT> and wasmtime run -Ddebugger=<COMPONENT>, providing a good debugging experience for WASI-CLI programs.

We should build the top-level plumbing to allow attaching debug components, both custom ones and the built-in gdbstub one, to wasmtime serve request handlers as well.

The challenge that occurs in this environment is that there is not just one program lifetime, but a Store lifetime per HTTP request (modulo instance reuse). Both the gdbstub protocol, and the underlying debug-main environment, are oriented around debugging one program execution from start to finish.

There are three general approaches I can imagine:

• Treat each HTTP request as a program execution. This would spawn an instance of the debug component alongside the instance of the wasi-http component. That debug component could listen for a gdbstub connection before continuing, like wasmtime run today. When the one request is done, LLDB sees this as "process exited".
• Somehow stitch together all HTTP requests into one "virtual program execution" from the point of view of the debugger WIT API. In practice this would mean persisting some state (which breakpoints are set, for example). It would also imply building an invalidation mechanism for all Instance/Module/Table/Global/Func/... handles at the debug API level.
• Lean into instance reuse, and only have one long-running wasi-http component when we have debugging enabled.

The top-level user experience we probably want is something like: attach LLDB; set a breakpoint somewhere in a handler in a wasi-http component; get control and step through code after sending an HTTP request.

Option 1 is thus a terrible user-experience that we want to reject, I think. Either option 2 or option 3 could provide this desired experience. I favor option 3 for simplicity, in the sense that it bends the conceptual model the least, but I'm curious what others think as well!

Wasmtime GitHub notifications bot (Mar 14 2026 at 22:43):

bjorn3 commented on issue #12776:

Gdb supports attaching to multiple inferiors at the same time if you connect using target extended-remote: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Inferiors-Connections-and-Programs.html The gdbstub crate doesn't properly handle this yet (https://github.com/daniel5151/gdbstub/issues/124). It should however support attaching to a single specific remote process at a time. So you could expose one "process" per store. Only debugging multiple stores at the same time wouldn't work. https://docs.rs/gdbstub/latest/gdbstub/target/ext/extended_mode/trait.ExtendedMode.html LLDB also supports attaching to a specific remote process. I don't know if it supports having multiple inferiors at the same time.

Wasmtime GitHub notifications bot (Mar 14 2026 at 22:48):

bjorn3 commented on issue #12776:

Exposing each store as a separate thread would also be an option, though LLDB doesn't support non-stop debugging afaik (GDB does together with many other features that LLDB doesn't have any kind of equivalent to, but doesn't support wasm debugging unfortunately), so all requests would be blocked while debugging a single request.

Last updated: Mar 23 2026 at 16:19 UTC