Open FredrikNoren opened 1 year ago
Ok I did get breakpoints to work for the fib-debug example now, I just had to add "settings set plugin.jit-loader.gdb.enable on" to launch.json, so it looks like this now (this is osx specific, see: https://github.com/bytecodealliance/wasmtime/issues/1953):
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
"type": "lldb",
"request": "launch",
"program": "target/debug/fib-debug",
"args": [],
"initCommands": [
"settings set plugin.jit-loader.gdb.enable on"
]
},
]
}
I tried the same with ambient but it didn't work (yet)
@philpax Hm I think it might be something about it not finding the right files; I noticed that in the fib-debug example they have this line:
let module = Module::from_file(&engine, "target/wasm32-unknown-unknown/debug/fib.wasm")?;
but I can't find anything like that in our code. Is there some place where it might be setting up what the local path is to the source files?
Hm, our setup is a little finicky.
ambient_build
builds the raw WASM files using cargo
, which produces a WASM file targeting wasm32-wasi
(wasi_snapshot_preview1
). This is then adapted to a WASM component using an adapter, and the resulting component is outputted to the build folder:
The component bytecode is then loaded into the ECS:
Some indirection later, the WASM is instantiated with the bytecode:
If I were to guess, the componentization process might be interfering. That being said, neither Module::from_file
or Component::from_file
pass in the path, so maybe it's entirely based on relative paths?
I'd peek around the textual WebAssembly for both fib-debug
and one of our modules, and see if you can spot where the debug paths point to.
This might be relevant: https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging (thanks to ju_rstr in the discord!)
The next release of wasm-bindgen should have this merged in https://github.com/rustwasm/walrus/pull/244 Main issue here: https://github.com/rustwasm/wasm-bindgen/issues/2389 cc @ten3roberts
Nice.
I tried debugging wasm going as manual as possible through both commandline lldb, gdb, and rust-lldb.
I could sortof get it to work, but was not able to get the original rust code or function named breakpoints to work, though I did manage to stop inside the wasm on panics and other traps.
The next release of wasm-bindgen should have this merged in rustwasm/walrus#244 Main issue here: rustwasm/wasm-bindgen#2389 cc @ten3roberts
@Nuno, I think you may have misunderstood the issue. This is about debugging guest code jitted wasm run inside wasmtime, which does not use wasm-bindgen at all.
wasm-bindgen is only used to bind to javascript APIs and functions such as fetch
, window
, WebTransport
, performance.now
etc which allows the web client to talk back to js and produce any side effects. This is totally unrelated to guest wasm debugging, unfortunately
But it would be helpful if we could debug and set breakpoints with the browser, right? My understanding is that now we aren't able to because wasm-bindgen doesn't update DWARF after transformations: https://twitter.com/ChromeDevTools/status/1192803949759348736
New projects now have a
launch.json
(for vscode) which launches the project with code-lldb. This works fine, except it doesn't seem to handle debugging/breakpoints yet.I tried adding
.debug_info(true)
on wasmtimes'sConfig
, but it didn't seem to have any effect.There's this example in wasmtime; https://docs.wasmtime.dev/examples-rust-debugging.html but I couldn't get that to work with breakpoints either.