Hi currently is there a way to debug a WASM module, like tracing what's happening in the runtime user space.
One option is WASMTIME_LOG=wasmtime_wasi
if you're using the wasmtime
CLI, otherwise if you have your own embedding wasmtime-wasi
-the-crate will emit log messages to tracing::trace!
if you're using node to run the wasm module there's --trace-wasm
option that prints wasm function calls, you can find other similar options in node --v8-options
@Alex Crichton Is this tracing only the "syscalls" calling into the runtime, (the hostfunctions?)
Correct yeah, just the imports into wasi
Do you have your own embedding of Wasmtime, are you using the wasmtime
CLI, or are you using another runtime entirely?
Oh yeah, I'm using Wasmer actually, and I'm trying debug what's happening in the user space. Since we compiled glibc to wasm, which is extremely complex, now we can hardly debug any error in the user space, while the syscalls are actually "sparse".
Ah ok, sorry I was making a wrong assumption. I fear I will not be of much help in this case
Oh that's fine, no worries. Is there any plan of the community to support debugging in the user space? Like a gdb for wasm
We do have very basic support for use of gdb in wasmtime (attach gdb to the host process)
We don't develop Wasmer here (that's made by a different company) so we unfortunately cannot answer any questions related to that
Here's a link regarding Wasmtime's debug support: https://github.com/bytecodealliance/wasmtime/blob/main/docs/examples-debugging-native-debugger.md
@Chris Fallin Oh we don't really rely on Wasmer, we are a research group at NYU and we mainly work on porting glibc to wasm, we just use the runtime to expose a hostfunction that trivially relays syscalls to our own library OS. We can also move to wasmtime without much engineering overhead. But right now debugging the glibc inside a WASM runtime is our most imminent issue.
@Joel Dice Thank you! Trying to use this.
lldb works pretty well in general, though some of the local types don't resolve, but you can mostly walk through. You can see me doing that here with the codelldb vscode extension and rust, c, c++ code bases using wasmtime; should work with any runtime, depending on what they use to project the dwarf into the module. YouTube - Nobody Knows the Trouble I've Seen: Debugging Wasm for web and server by N. Venditto & R. Squillace.
if you're using components, you're out of luck at the moment.....
have a look at https://github.com/squillace/c-wasm-debug/blob/8e97279bf5dd44e585da0080b1aad2299ae2a9d9/.vscode/launch.json#L12-L19 for an example lldb invocation.
Not sure that repo still works, but the configuration is correct whether you use vscode or not.
Ralph said:
if you're using components, you're out of luck at the moment.....
Oh I'll note that this changed in https://github.com/bytecodealliance/wasmtime/pull/8693 and components + lldb should be supported now
Yeah yeah, we just tried gdb
with wasmtime + wasi-libc, that's really amazing. Just note that, we shouldn't attempt any interaction with instructions, like si
, which will break the gbd. Other than this, things works really well.
Thank you guys!
Alex Crichton said:
Ralph said:
if you're using components, you're out of luck at the moment.....
Oh I'll note that this changed in https://github.com/bytecodealliance/wasmtime/pull/8693 and components + lldb should be supported now
wait WUT you people are AMAZING --- off to test...
Last updated: Dec 23 2024 at 12:05 UTC