-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow keeping debug symbols in the generated wasm output in release builds #135
Comments
@jbg that's a good idea. We can actually just add a new option to the Rust asset type pipeline type. Folks would then be able to do something like: This should be quite simple to add to the pipeline. If you are interested in contributing a PR, that would be excellent. That would get you 90% of the way there. That last bit would be to add some tooling around |
Cool, sounds like a good approach. I'll take a stab at it tomorrow. |
It really seems as though this would be a perfect use case for the plugin system (the wasm-split aspect of this). Especially given that wasm-split does not yet ship pre-compiled, so folks are expected to build it on their own. A plugin for this would be perfect as it is somewhat niche. |
These new data-* options for <link rel="rust" .../> influence the way that Trunk invokes wasm-bindgen, invoking the --keep-debug & --no-demangle options respectively. closes #135
These new data-* options for <link rel="rust" .../> influence the way that Trunk invokes wasm-bindgen, invoking the --keep-debug & --no-demangle options respectively. closes #135
We're currently looking at improving error reporting from some WebAssembly running in the browser, and we're having trouble getting trunk to produce a .wasm file that includes DWARF debug info. We want to be able to split off that debug info, store it, and use it to symbolicate any reported errors.
Setting
debug = true
in the release profile inCargo.toml
isn't sufficient becausewasm-bindgen-cli
strips the debug info when run in release mode unless--keep-debug
is passed.I guess eventually it would be cool if trunk could (optionally) split off the debug info itself and output it separately, but for now it would be sufficient if there was a way to get
--keep-debug
passed towasm-bindgen-cli
(somewhere around here) and then we can separately run wasm-split afterwards.The text was updated successfully, but these errors were encountered: