Debugging & Breakpoints

[FredrikNoren]

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's Config, 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.

[FredrikNoren]

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: bytecodealliance/wasmtime#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)

[FredrikNoren]

@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?

[philpax]

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:

Ambient/crates/build/src/lib.rs

Lines 105 to 113 in fc3ae02

	for (path, bytecode) in rustc.build(project_path, manifest.project.id.as_ref(), optimize, &[feature])? {
	let component_bytecode = ambient_wasm::shared::build::componentize(&bytecode)?;
	let output_path = build_path.join(feature);
	std::fs::create_dir_all(&output_path)?;
	let filename = path.file_name().context("no filename")?;
	tokio::fs::write(output_path.join(filename), component_bytecode).await?;
	}

The component bytecode is then loaded into the ECS:

Ambient/app/src/server/wasm.rs

Lines 64 to 71 in fc3ae02

	if target == "client" {
	let relative_path = path.strip_prefix(&build_dir)?;
	let bytecode_url = format!("{}:/{}", ASSETS_PROTOCOL_SCHEME, relative_path.to_string_lossy());
	world.add_component(id, client_bytecode_from_url(), bytecode_url)?;
	} else {
	let bytecode = std::fs::read(path)?;
	world.add_component(id, module_bytecode(), ModuleBytecode(bytecode))?;
	}

Some indirection later, the WASM is instantiated with the bytecode:

Ambient/crates/wasm/src/shared/module.rs

Lines 191 to 198 in fc3ae02

	let mut linker = wasmtime::component::Linker::<WasmContext<Bindings>>::new(engine);
	ambient_wasmtime_wasi::add_to_linker(&mut linker, |x| &mut x.wasi)?;
	wit::Bindings::add_to_linker(&mut linker, |x| &mut x.bindings)?;
	let component = wasmtime::component::Component::from_binary(engine, component_bytecode)?;
	let (guest_bindings, guest_instance) =
	wit::Bindings::instantiate(&mut store, &component, &linker)?;

---

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.

[FredrikNoren]

This might be relevant: https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging (thanks to ju_rstr in the discord!)

[Pombal]

The next release of wasm-bindgen should have this merged in rustwasm/walrus#244
Main issue here: rustwasm/wasm-bindgen#2389
cc @ten3roberts

[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.

[ten3roberts]

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

[Pombal]

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