Alexandru Ene (May 02 2020 at 16:19): Alexandru Ene (May 02 2020 at 16:19):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?
Steve Williams (May 02 2020 at 16:23):also interested in this.
bjorn3 (May 02 2020 at 16:35):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.
Steve Williams (May 02 2020 at 16:36):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.
bjorn3 (May 02 2020 at 16:38):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.
bjorn3 (May 02 2020 at 16:38):$ 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.
Alexandru Ene (May 02 2020 at 16:39):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?
bjorn3 (May 02 2020 at 16:39):@Alexandru Ene Yes
Alexandru Ene (May 02 2020 at 16:40):So I assume if this works, attach to process also works, LLDB doesn't necessarely have to start it?
bjorn3 (May 02 2020 at 16:40):@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.
Steve Williams (May 02 2020 at 16:41):think we both have the same question/config.
bjorn3 (May 02 2020 at 16:41):To register the debuginfo, wasmtime calls a specially named function. That function does nothing when normally running, but lldb intercepts the call.
Steve Williams (May 02 2020 at 16:42):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.
Alexandru Ene (May 02 2020 at 16:42):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)
Steve Williams (May 02 2020 at 16:45):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.
Alexandru Ene (May 02 2020 at 16:47):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
bjorn3 (May 02 2020 at 16:53):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.
Alexandru Ene (May 02 2020 at 16:59):This is super helpful. In addition to this is extra work needed to provide support for breakpoints/variable inspection/etc in the wasm code?
bjorn3 (May 02 2020 at 17:00):When the wasm file has debuginfo, breakpoints and variable inspection should already work.
Alexandru Ene (May 02 2020 at 17:01):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
bjorn3 (May 02 2020 at 17:02):no problem
Alexandru Ene (May 02 2020 at 17:11):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.
bjorn3 (May 02 2020 at 17:14):Yes
Steve Williams (May 03 2020 at 07:47):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.
Yury Delendik (May 04 2020 at 14:53):@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
Yury Delendik (May 04 2020 at 14:53):/me is actively working on it, so appreciate any bugs or feedback
Yury Delendik (May 04 2020 at 14:55):there is test for LLDB at https://github.com/bytecodealliance/wasmtime/blob/master/tests/all/debug/lldb.rs
Alexandru Ene (May 04 2020 at 14:58):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
Alexandru Ene (May 04 2020 at 14:59):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.
Alexandru Ene (May 04 2020 at 15:00):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
Alexandru Ene (May 04 2020 at 21:00):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
Yury Delendik (May 04 2020 at 21:02):there will be issue for variables that are locations in memory/pointer/references
Yury Delendik (May 04 2020 at 21:03):there is a hack as documented at https://github.com/bytecodealliance/wasmtime/pull/1482
Last updated: Nov 22 2024 at 17:03 UTC