Support DWARF in wasm-bindgen

[mitsuhiko]

Motivation

Chrome, Firefox and now also Sentry support DWARF for WebAssembly as debug format. In particularly for crash reporting systems like Sentry DWARF is a very important tool to create accurate stack traces for production builds of web assembly applications.

This issue was previously brought up in #1981.

Proposed Solution

Most likely the bulk of the implementation will be in walrus (see rustwasm/walrus#67).

[Cypher1]

Just hoping for an update as this would be really handy for debugging WASM performance issues. Thx

[michael8090]

After some experiments, I find it's possible to show Rust code in the Chrome DevTools with the following steps:

1. add a --keep-debug in wasm-bindgen when building the wasm file, i.e. wasm-bindgen --keep-debug --out-dir ...
2. install a C++ chrome extension and enable DWARF support feature in chrome dev tools: https://developer.chrome.com/blog/wasm-debugging-2020/?utm_source=devtools

Then the rust code can show up in the dev tools, but other functionalities such as setting breakpoints and evaluating rust code, are broken:

It seems the DWARF info is kept when using wasm-bindgen with --keep-debug, but chrome doesn't fully support the dwarf debugging features for rust code.

[CryZe]

It seems more like the debug info is "broken" after wasm-bindgen processes it, as in enough to make the source show up, but not enough for Chrome to handle it.

[michael8090]

It seems more like the debug info is "broken" after wasm-bindgen processes it, as in enough to make the source show up, but not enough for Chrome to handle it.

The extension is for C++ only, and you can see when I try to evaluate ElementsManager::get_static() in console, it takes the string as C++ code and says it's an invalid one. My guess is that maybe the dwarf info is correct, but it's the C++ extension that cannot understand rust code. I hope maybe someone inside the extension project or wasm-bindgen can give some concrete information about it.

[CryZe]

Yeah, calling methods and stuff almost definitely won't work, but local variables and their fields, and breakpoints are all things that should work and last I tested DO work... if you don't use wasm-bindgen. So that still seems like a strong indication that the dwarf is broken.

[stan-irl]

@CryZe did breakpoints work for you?? The devtools find my rust code but none of the standard library or cargo packages. They are all prefixed like /cargo/... or /rustc/...

[RReverser]

but none of the standard library or cargo packages. They are all prefixed like /cargo/... or /rustc/...

It's expected and happens because standard library in Rust is prebuilt on CI with those paths hardcoded. You can remap them to either github or your local rust-src paths via the extension settings.

But, either way, the breakpoints won't work at the moment because, as mentioned above, DWARF remapping is not implemented in wasm-bindgen.

[stan-irl]

got it! thankyou for the quick response 🙏

[RReverser]

But, either way, the breakpoints won't work at the moment because, as mentioned above, DWARF remapping is not implemented in wasm-bindgen.

Should probably clarify that this is only if you use wasm-bindgen. If you use raw Wasm, it will work (but that's uncommon on the web).

[stan-irl]

ah i got. because wasm-bindgen is actually changing the wasm when it generates the bindings but its not changing the DWARF so nothing matches up.

Regular wasm doesnt do that so its not a problem

[71]

Note: with a few changes, I managed to successfully step through wasm-bindgen'd Rust code in Chrome using @nokotan's fork of walrus. See rustwasm/walrus#231 (comment).

However, that fix is very much non-production ready. As I mentioned in the comment linked above, it requires several forks of existing libraries, including wit-walrus which is not maintained anymore (since WIT no longer seem active). wasm-bindgen-cli-support would need a lot of work to drop the dependencies on WIT-related crates, so for now that dependency needs to stay. Once that's done, we'd need to make sure the PR I linked above would be merged. Since DWARF doesn't seem to work well with Chrome (at least on Windows), we'd also need make our own version of wasm-sourcemap.py (since a Python dependency on top of Rust and JS would be a bit much).

Note: I'd like to get more involved with wasm-bindgen (and its dependencies), so if any maintainer sees this and can point me to tasks that would help make this possible, please do!

[Cldfire]

Since DWARF doesn't seem to work well with Chrome (at least on Windows), we'd also need make our own version of wasm-sourcemap.py (since a Python dependency on top of Rust and JS would be a bit much).

Someone has now built this, and playing around with it locally it seems like it works well: https://github.com/mtolmacs/wasm2map

[RReverser]

@Cldfire FWIW that comment above was mistaken, DWARF does work well with Chrome directly: rustwasm/walrus#231 (comment)

[d3lm]

Yea, I can also confirm that DWARF works well for me with Chrome, at least on macOS (M1).

[connor4312]

VS Code's JavaScript debugger is also now DWARF aware (nightly build today, and to stable in 2 weeks). Support here would make targeting wasm from Rust much more pleasant for VS/Code folks 🙂

[daxpedda]

Just for visibility: this is currently only blocked on rustwasm/walrus#247.

[eiswind]

for visibility: rustwasm/walrus#247 has been fixed.

[connor4312]

Awesome! Can't wait to give this a shot on Monday... so I'll probably try it this weekend 😄

[squillace]

Well..... @connor4312 ????? I'm on tenterhooks and I believe this is more important than Thanksgiving because if it works I can give thanks!

[haraldreingruber-dedalus]

How is it decided when new wasm-bindgen versions are released? On demand?
Looking forward to giving the next release a try 😎

[connor4312]

I'm on tenterhooks and I believe this is more important than Thanksgiving because if it works I can give thanks!

At cursory investigation, things work with a few caveats:

• Publishing of packages still needs to happen. Also, I can only get symbols working if I invoke wasm-bindgen directly with --keep-debug, not via the more common wasm-pack, but maybe this'll be fixed when things are published?
• Locations work in the Chrome C++ extension but they're off in VS Code's debugger. This is likely on my side to fix; we consume the guts of the Chrome plugin to do the DWARF heavy lifting so I'm probably just holding it wrong. I will look after the holiday.

[d3lm]

How is it decided when new wasm-bindgen versions are released? On demand?

@haraldreingruber-dedalus I think this should be released. Or maybe I am mistaken.

[connor4312]

Fixed in VS Code, will be released in about 1.5 weeks from today

Will be looking forward to a new version of wasm-bindgen/wasm-pack so we can update our docs with Rust debugging instructions :)

[RReverser]

@connor4312 It looks like the call stack name is not taken from DWARF but rather from the names section? Is that a currently known limitation?

[connor4312]

that's formed from asking the worker for getFunctionInfo, which is the same (from what I understand) as what the devtools extension does. I get the same result there, maybe the issue is upstream?

[RReverser]

Ah weird, could be. It's been couple of years since I tried Rust-produced Wasm in DevTools. I guess they'd need Rust-specific demangling to omit it. Not a big deal either way, thanks for working on this!

[brentmjohnson]

@connor4312 thanks so much for the work on this! I kind of expected this to be released to vscode-insiders but maybe not yet? rustwasm/walrus dependency upgrades are now in the 0.2.89 release (diff)

[connor4312]

It's in tomorrow's Insiders

[michael8090]

Thanks for the wonderful work. I played for a while and found the following:

1. breakpoint, stepping: works nicely, great
2. local variable inspecting: it shows undefined for every local variable, no idea if it's something I did wrong:

3. function arguments inspecting: arguments are `undefined` except `self`. `self` can be fully expanded, and some `owned` values can be inspected properly, but boxed values are hidden behind pointers, which makes them hard to be inspected: