AmbientRun / Ambient

The multiplayer game engine
https://ambient.run
Apache License 2.0
3.8k stars 124 forks source link

Debugging & Breakpoints #305

Open FredrikNoren opened 1 year ago

FredrikNoren commented 1 year ago

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 commented 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)

FredrikNoren commented 1 year ago

@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 commented 1 year ago

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:

https://github.com/AmbientRun/Ambient/blob/fc3ae0235ad84678b07c2486460b28e900b0e7c0/crates/build/src/lib.rs#L105-L113

The component bytecode is then loaded into the ECS:

https://github.com/AmbientRun/Ambient/blob/fc3ae0235ad84678b07c2486460b28e900b0e7c0/app/src/server/wasm.rs#L64-L71

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

https://github.com/AmbientRun/Ambient/blob/fc3ae0235ad84678b07c2486460b28e900b0e7c0/crates/wasm/src/shared/module.rs#L191-L198


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 commented 1 year ago

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

Pombal commented 1 year ago

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

ten3roberts commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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