I saw this from Mozilla about WASMTtime debugging outside the browser https://hacks.mozilla.org/2019/09/debugging-webassembly-outside-of-the-browser/ and I am interested in a bit more details on it.
Is the debugging support specified anywhere?
I can't figure out at the moment what would it take to make WAMR or WASM3 support that type of lldb debugging (or maybe they support it and i can't find the documentation). Where can I start reading about the internals that make this possible?
also interested in this.
If you are using the wasmtime
binary, you need to pass -g
. If you use the C api, you need to call wasmtime_config_debug_info_set(config, true);
. If the wasm file was built with debuginfo, you can then just launch the embedder in lldb and it should work.
so lldb runs as a seperate process & if you config like that you hook up a pipe between yourself & it or something like that ?
cool. this is going to be less work than I thought.
You use lldb like you would normally debug a native process, except that you need to debug the embedder (the user of wasmtime) and not the wasm binary itself. Wasmtime will then generate the necessary debuginfo and pass it to lldb.
$ lldb /path/to/embedder
that's not going to work for us. lldb can't start our process. its got to hook into something already running.
Can I debug both like this? set breakpoints in the program that linked with wasmtime (or another vm) and the WASM code in the same session?
@Alexandru Ene Yes
So I assume if this works, attach to process also works, LLDB doesn't necessarely have to start it?
@Steve Williams You can attach to a running process, but if the wasm instance was created before you attached lldb, the debuginfo will probably not be registered to lldb.
think we both have the same question/config.
To register the debuginfo, wasmtime calls a specially named function. That function does nothing when normally running, but lldb intercepts the call.
we can start our stuff with whatever configuration is required - start in developer mode, but the point is we'll be running before the debugger hooks in.
That's ok, I assume I can do this by waiting for a debugger to attach kind of setup (similarly to how you debug a JS VM outside the browser for ex)
lldb could potentially kick off our entire process tree & as your stuff is in our root process right now that'd work. looking forward to experimenting, but framework first. thanks all for your continued assistance.
This is extremly cool. is this debug support tested as part of a sort of wasm compliance test suite for VMs? Or is it a new feature that isn't yet implemented everywhere? Also for a more detailed thing, what's the lldb method called? or where does the call happen? Searching for debug in the repo is a bit hard to follow :D
Debug support is not necessary for wasm compliance. The spec is https://yurydelendik.github.io/webassembly-dwarf/. The lldb intercepted function is __jit_debug_register_code
.
This is super helpful. In addition to this is extra work needed to provide support for breakpoints/variable inspection/etc in the wasm code?
When the wasm file has debuginfo, breakpoints and variable inspection should already work.
Actually this is already addressed in the doc you linked. That's why it needs to be generated. Thanks a lot this is super cool
no problem
Ahh, so basically it relies on the generated JIT for debugging, that's why the only thing that's needed is the fixed-up debug info.
Yes
would love to see wasmtime communicate (optionally) with lldb in a seperate process via a pipe if we ask it to connect at some point.
on a per instance basis. one or more things will be debugged. anything else we'd like to run as normal.
that way we can kick off debug sessions as needed from within our environment rather than have to run our entire system under a debugger for web dev debugging.
I think it'll run more efficiently that way. far too early for this. don't need it yet, got plenty to be getting on with & there appears to be a solution that works, which is effectively the same as we have to do under visual studio to debug .net stuff.
... but visual studio .net parity is not the aim here, excellence is.
metioned now so we can think about it a little & how it might work. no rush.
@Alexandru Ene give it a try, though friction-free running is happening on Linux atm. MacOS need additional option for LLDB be provided to enable JIT'ed code. Not tested on Windows
/me is actively working on it, so appreciate any bugs or feedback
there is test for LLDB at https://github.com/bytecodealliance/wasmtime/blob/master/tests/all/debug/lldb.rs
Hi, yes, I did give it a try and it just work (tm) :D
I am super happy to be honest. It is wokring out of the box on windows with CodeLLDB
In general I think the support WASMTime has for debugging is awesome, I wish this was a standard for all VMs, as it's unclear at the moment how much work would it be to include this in WAMR for ex.
There is one slight downside of this for people who run WASM outside their browser and on funky devices, debugging becomes more tricky, as for ex there's no equivalent like you have in the JS world where the debugger can remotely connect to the VM
But this means it's on par with C++ native experience on those devices so I guess it's fine from my point of view
There seems to be issues with visualizing values captured by closures on LLDB, so not sure why that happens. That being said, i can't inspect values captured by clojures if I build as a native rust app either, so likely not an issue of wasmtime's dwarf handling
there will be issue for variables that are locations in memory/pointer/references
there is a hack as documented at https://github.com/bytecodealliance/wasmtime/pull/1482
Last updated: Dec 23 2024 at 12:05 UTC