Hi, I've seen that wasmtime supports debugging wasm using regular debuggers but I can't seem to get it to work.
I've tried copying the rust code verbatim from this video, compiling with rustc --target=wasm32-wasi fizzbuzz.rs
and running lldb -- wasmtime -g fizzbuzz.wasm
, but setting a breakpoint with b fizzbuzz
and running with r
just runs the code as normal; no breakpoint is triggered.
I've also tried with gdb, with similar results
Seems like I was using an outdated version of wasmtime, working now! :)
Is -g
still an option for wasmtime or is it now -D debug-info=y
?
i.e. when given a WASM file compiled from dwarf LLVM bitcode?
it'd -D debug-info
, which is equivalent to -D debug-info=y
.
I figure we can reintroduce -g
if necessary though
A follow up if I may. Is there a way in LLDB to print class static fields from a c++ object?
I try
(lldb) p WKS::gc_heap::g_low_memory_status
error: Couldn't lookup symbols:
WKS::gc_heap::g_low_memory_status
But it can't find the symbol.
I've never used lldb with wasmtime to that degree, so not sure myself (presuming you're debugging guest code?)
Yes, that's right. No problem, I can revert to printfs for these.
or copy to locals on the frame, those work fine
lldb / gdb seem to work well with the 13.0 release for me. However I've only been able to get them to work with wasm on Linux. Has anyone had any luck on Windows? (Our ecosystem is mostly comprised of Windows users, so a debugging workflow that works for them would be great)
SingleAccretion on github may know more given PRs like this, but I've not done it myself
Thanks yes that env var is essential. LLDB works for me on Windows, modulo not being able to view c++ class statics. @CryZe I had to build wasmtime from source, the prebuilt binary didn't work for me.
lldb also works from VS Code for me with Rust on Windows, although I'm not sure I understand how to form all the command args properly for lldb with cargo
@Scott Waye I've tried the CodeLLDB extension on Windows and it does not pick up any wasm debug symbols, unlike the same extension on the same code on Linux. Are you using a different extension? Or none at all?
Wait, after trying it again right now. It totally does work... nvm then, thanks :D
Hi there. I'm Artem from the Kotlin/Wasm team. We started to play around with DWARF generating and the wasmtime debug described here: https://docs.wasmtime.dev/examples-debugging-native-debugger.html
I faced the problem of setting a breakpoint by file name and line number on a non-clang-generated DWARF.
I've minimized an example and just tried to use debug information generated by wasm-tools (https://github.com/bytecodealliance/wasm-tools) while parsing a WAT file and still, I have stopped by function name, but not by file name/line number.
Do you use the information provided by the .debug_line section, and (if yes), do you use some heuristics on it?
I suspect this is a case where DWARF basically needs to look like what clang generates for gdb/lldb to understand it (similar to how in Rust we often have to look exactly like Clang to get optimizations to kick in). When I wrote the support for -g
in wasm-tools
I didn't test in Wasmtime other than doing things like addr2line
operations. I'm certainly no dwarf expert myself so I suspect a section is missing or something like that.
Wasmtime should translate all the various DWARF sections as necessary, but my guess is that there's some missing link between function debug information and .debug_line
(or something like that). I don't know enough about LLDB/GDB though to know which section is missing.
If you find out though let me know and I can try to update the dwarf support in wasm-tools
(which I realize may not be relevant for your exact use case but is probably useful to have anyway)
You need a DW_TAG_compile_unit which covers all functions in the line program (using DW_AT_ranges or DW_AT_low_pc + DW_AT_high_pc) and additionally a DW_AT_stmt_list pointing to the line program itself.
I like a person who knows their dwarf requirements
Last updated: Dec 23 2024 at 14:03 UTC