Add --emit-module-names to wasm-opt#8860
Conversation
The `wasm-split` command has this `--emit-module-names` flag already and this adds it to `wasm-opt` as well. Wasm runtimes may not know the URL where a wasm file came from, it may only be given the bytes. Currently e.g. V8 prints a V8 specific hash of the wasm file in stack traces. If we have the ability to keep module names, then it would print the module name (fallback if the url is not available) -- which would allow a stack trace decoding tool to tie the module name back to the right wasm module of an app.
|
|
It's not clear to me that the fix for that chromium issue constitutes a "simpler way of naming modules," so I'd be happy to have this flag added to |
Precisely. The V8 bug was closed by making V8 stack frames contain a hash of the module bytes via an V8-internal hash function -- outside tooling that gets a stack trace with those hash codes cannot do anything with them (it's not a wasm spec'ed hash code function) |
|
I've moved the option to |
| void setSourceMapUrl(std::string sourceMapUrl_) { | ||
| sourceMapUrl = sourceMapUrl_; | ||
| } | ||
| void setEmitModuleName(bool set) { emitModuleName = set; } |
There was a problem hiding this comment.
In general we prefer functions like this over booleans passed to constructors - the boolean is less explicit about what it is.
I get the idea that making it non-optional is safer, but it is less clear when reading the code, and tests can check that we do actually use this properly. So I think it would be better to keep setEmitModuleName and use that from the tools. Though I hope we can wrap around wasm-io in the tools so they all use a shared path? Perhaps adding a helper function to ToolOptions "write" which does all the writing, applying this flag as needed?
|
Thanks for merging, @kripken ! |
3 participants
The
wasm-splitcommand has this--emit-module-namesflag already and this adds it towasm-optas well.Wasm runtimes may not know the URL where a wasm file came from, it may only be given the bytes.
If so, then e.g. V8 prints a wasm-runtime-specific hash of the wasm bytes in stack traces. If a stack trace has
frames of different wasm modules, these hashes do not allow mapping the frames back to the original wasm files.
If we have the ability to keep module names, then it would print the module name (**) (instead of the hash) --
which would allow a stack trace decoding tool to tie the module name back to the right wasm module of an app.
(**) It prefers the wasm file url. If that isn't available it falls back to module name. If that isn't available it falls back to hash of wasm bytes.
See also https://issues.chromium.org/issues/42201791