Be able to debug WASM modules

[repi]

We currently can't debug our WASM modules (that we run not in a browser), this will become a bigger and bigger issue going forward so we should investigate what are the paths for getting some type of debugging support either with wasmer or wasmtime.

We would want it to be super easy to debug the code for a small (or big) WASM module directly in VS Code as well as in other editors.

Related:

• wasmer: Add support for step debugging and Virtual Machine introspection

[pepyakin]

A probably related link, screencast of debugging with wasmtime.

[tschneidereit]

I'd be interested in hearing more about what you need to fully address this. As shown in the link @pepyakin posted, we support LLDB debugging on Linux and macOS in Wasmtime, which hopefully should go a long way to addressing this. Windows is trickier, but apparently feasible.

Beyond just supporting more platforms, are there specific features or pieces of functionality you'd need for this to be usable?

[repi]

@tschneidereit sorry I missed your comment here, so very late reply ☹

the wasmtime work on debugging looks promising! though assume it is primarily working for loose WASM modules loaded & run through the wasmtime executable host?

The use case we after is debugging WASM modules loaded by our own executable host that embeds a WASM runtime engine (like wasmtime), and ideally debugging using VS Code or other standalone IDE debuggers. Though I a CLI-based debugger interface like GDB/LLDB could also be a start.

Have there been any more developments with wasmtime around debugging and would the debugging support that it has be able to be used in the context of wasmtime embedded into our own executable host (that also implements multiple of our own WASM FFI APIs).

As for platforms, we work pretty evenly split between Windows, Linux and Mac OS. Though having an initial solution that works on Linux & Mac that would work for most of us

[tschneidereit]

@repi no worries at all! 🙂

The use case we after is debugging WASM modules loaded by our own executable host that embeds a WASM runtime engine (like wasmtime), and ideally debugging using VS Code or other standalone IDE debuggers. Though I a CLI-based debugger interface like GDB/LLDB could also be a start.

If I understand the use case correctly, that should work perfectly well: Wasmtime debugging is not in any way tied to the wasmtime CLI. You should be able to connect a debugger to the host application and step through it as you normally would, and things should continue working when stepping into a Wasm call.

By the same token, debugging in VS Code should work just the same as it would for debugging the host application.

Have there been any more developments with wasmtime around debugging and would the debugging support that it has be able to be used in the context of wasmtime embedded into our own executable host (that also implements multiple of our own WASM FFI APIs).

How the Wasm/host context switch happens shouldn't make much of a difference, so the fact that you have your own FFI APIs shouldn't affect things much. (Also, I'd be amiss if I didn't mention the possibility of defining host APIs using witx, as described in this very nice post by @radu-matei.)

As for platforms, we work pretty evenly split between Windows, Linux and Mac OS. Though having an initial solution that works on Linux & Mac that would work for most of us

Windows should actually work by now. We haven't tested it too much, but debugging in VS Code using LLDB seems to work just fine.

If you end up looking into this more, don't hesitate to reach out and let us know if you run into issues — or just generally how things are going, and what could be improved!

[repi]

@tschneidereit oh that is good news! both that debugging with LLDB of WASM modules should just work inside VSCode and for Windows. we'll try it out!

Also, I'd be amiss if I didn't mention the possibility of defining host APIs using witx, as described in this very nice post by @radu-matei.)

Interface types and WITX is one of the things we've been eyeing and are interested in trying out with wasmtime, haven't seen that specific article though so that is a good resource, thanks!

We have a pretty extensive set of versioned private APIs right now that we define the FFI and Rust interfaces for using Rust + some proc macros that @Jake-Shadle created. A bit like wasm-bindgen macros with higher-level types in but where we generated both the FFI and the safe host and module Rust APIs for, it is a but custom for our use though but has been a good help.

If you end up looking into this more, don't hesitate to reach out and let us know if you run into issues — or just generally how things are going, and what could be improved!

Thanks, we are starting up looking into wasmtime and experimenting with it in more detail now again and was planning to reach out to you all soon when we have some more concrete topics and questions to discuss

[bnjbvr]

Our in-house wasmtime embedder now has the ability to enable debug information generation, which is a huge improvement over printf debugging 🎉

Right now, this enables us to run our app in a recent version of LLDB, and then allows us to:

• set breakpoints in wasm code generated from rust,
• use control flow debugging commands (next, step, etc.) to observe control flow,
• look at the backtrace (on platforms where unwinding is fully supported, that is, not aarch64-darwin right now)
• in some cases, even inspect the content of variables (local, parameters, etc.), after running the __vmctx->set() lldb command. Yet it is a bit fragile: in some cases we're getting the escape hatch warning ("variable may have been optimized out"), which is fine, but in other cases we're seeing trash values in place of what should be correct. I'll try to make smaller repros, so as to report them to wasmtime's main repository. During latest Cranelift's meeting we even talked about what could be one cause of these bugs.

Overall it's pretty nice that enabling debug info support was just a configuration toggle to enable, and people in the wasmtime's zulip have been pretty helpful explaining how to get variable inspection to work at all!

We can consider this particular issue closed: while debugging support is not complete yet, we now have some debugging support, that is a very nice start and something we can build upon.