Skip to content

wasm-emscripten-finalize doesn't preserve sourcesContent #6805

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

Closed
verhovsky opened this issue Aug 2, 2024 · 1 comment · Fixed by #7473
Closed

wasm-emscripten-finalize doesn't preserve sourcesContent #6805

verhovsky opened this issue Aug 2, 2024 · 1 comment · Fixed by #7473

Comments

@verhovsky
Copy link

verhovsky commented Aug 2, 2024

If you can't host the files for your source map, you can put their contents in the sourcesContent field of your source map JSON file https://tc39.es/source-map/#sourcescontent

When emscripten runs wasm-emscripten-finalize on a source map file that has that field set

https://github.com/emscripten-core/emscripten/blob/cf0ec7a4426203d76f958216d14ad9f4513d8481/tools/emscripten.py#L488-L491

wasm-emscripten-finalize removes it.

emscripten-core/emscripten#22190

@verhovsky verhovsky changed the title wasm-emscripten-finalize doesn't preserve source map's sourcesContent wasm-emscripten-finalize doesn't preserve sourcesContent Aug 9, 2024
@dschuff
Copy link
Member

dschuff commented Apr 3, 2025

Thanks @mkl-ableton for pinging on this.
This applies to all of the Binaryen tools (including e.g. wasm-opt) and is because Binaryen regenerates the source map after it does its transformations (because of course transformations change the binary and therefore the mappings). But some information can just be passed through, including the list of source files in sources their content in sourcesContent (basically everything other than names and mappings). Currently the symbol and filename info just hangs off the Module object and gets read from and written into the source map during wasm binary reading and writing. It seems like it would be straightforward to add another field or two that passes directly through to the output. If the size of the sources gets to be too unwieldy, we could maybe represent them as indices or file offsets or something and pass them a little more directly/incrementally from the input to the output rather than keeping them attached to the Module in memory in between. But I'm not sure whether that would really be an issue or not.

dschuff added a commit that referenced this issue Apr 8, 2025
This is in preparation for fixing #6805.
Aside from cleaning up and reusing more code, it allows optional fields in the
source map and random access to those fields, rather than walking through
the whole JSON file just once. (It does keep the current behavior of
walking through the actual mappings in a single pass synchronized with reading
the binary). It also adds some unit tests.
dschuff added a commit that referenced this issue Apr 8, 2025
This is in preparation for fixing #6805.
Aside from cleaning up and reusing more code, it allows optional fields
in the
source map and random access to those fields, rather than walking
through
the whole JSON file just once. (It does keep the current behavior of
walking through the actual mappings in a single pass synchronized with
reading
the binary). It also adds some unit tests.
dschuff added a commit that referenced this issue Apr 9, 2025
Read the "sourcesContent", "file", and "sourceRoot" fields from incoming
source maps, attach them to the wasm IR module, and write them back to
the output source map. These fields are unchanged by Binaryen's
updates to the mappings, so they do not need to be decoded or interpreted.
Fixes #6805
dschuff added a commit that referenced this issue Apr 9, 2025
Read the "sourcesContent", "file", and "sourceRoot" fields from incoming
source maps, attach them to the wasm IR module, and write them back to
the output source map. These fields are unchanged by Binaryen's
updates to the mappings, so they do not need to be decoded or
interpreted.
Fixes #6805
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants