Update names field in source maps by aheejin · Pull Request #8068 · WebAssembly/binaryen

aheejin · 2025-11-26T01:21:24Z

This scans the code after optimizations and removes unused function names from 'names' field in the source map, reducing its size. Emscripten has not been generating 'names' field so far, but after emscripten-core/emscripten#25870, it will generate the field in case llvm-dwarfdump supports a new option --filter-child-tag.

This scans the code after optimizations and removes unused function names from 'names' field in the source map, reducing its size. Emscripten has not been generating 'names' field so far, but after #???, it will generate the field in case `llvm-dwarfdump` supports a new option `--filter-child-tag`.

This adds support for `names` field in source maps, which contains function names. Source map mappings are correspondingly updated and emsymbolizer now can provide function name information only with source maps. While source maps don't provide the full inlined hierarchies, this provides the name of the original (= pre-inlining) function, which may not exist in the final binary because they were inlined. This is because source maps are primarily intended for user debugging. This also demangles C++ function names using `llvm-cxxfilt`, so the printed names can be human-readable. I tested with `wasm-opt.wasm` from Binaryen by `if (EMSCRIPTEN)` setup here: https://github.com/WebAssembly/binaryen/blob/95b2cf0a4ab2386f099568c5c61a02163770af32/CMakeLists.txt#L311-L372 with `-g -gsource-map`. With this PR and WebAssembly/binaryen#8068, the source map file size increases by 3.5x (8632423 -> 30070042) primarily due to the function name strings. From `llvm-dwarfdump` output, this also requires additional parsing of `DW_TAG_subprogram` and `DW_TAG_inlined_subroutine` tags which can be at any depths (because functions can be within nested namespaces or classes), so we cannot use `--recurse-depth=0` (emscripten-core#9580) anymore. In case of `wasm-opt.wasm` built with DWARF info, without `--recurse-depth=0` in the command line, the size of its text output increased by 27.5x, but with the `--filter-child-tag` / `-t` option (llvm/llvm-project#165720), the text output increased only (?) by 3.2x, which I think is tolerable. This disables `names` field generation when `-t` option is not available in `llvm-dwarfdump` because it was added recently. To avoid this text size problem, we can consider using DWARF-parsing Python libraries like https://github.com/eliben/pyelftools, but this will make another third party dependency, so I'm not sure if it's worth it at this point. This also increased running time of `wasm-sourcemap.py`, in case of the `wasm-opt.wasm`, by 2.3x (6.6s -> 15.4s), but compared to the linking time this was not very noticeable. Fixes emscripten-core#20715 and closes emscripten-core#25116.

aheejin · 2025-12-04T00:19:32Z

Ping 😄

kripken

lgtm % comments

kripken · 2025-12-04T00:34:47Z

+
+    // Create the new list of names and the mapping from old to new indices.
+    uint32_t newIndex = 0;
+    for (auto& pair : oldToNewIndex) {


This is on an unordered map, so the indexing may end up nondeterministic, I worry?

Changed oldToNewIndex to std::map.

kripken · 2025-12-04T00:36:19Z

+    ;;@ src.cpp:2:1:used
+    (nop)
+  )
+)


Perhaps add another used symbol, to get some coverage of the order of the symbols being deterministic? (not great coverage, but it might help)

Done: a55a844

dschuff · 2025-12-04T00:53:02Z

+
+    // Collect all used symbol name indexes.
+    for (auto& func : wasm->functions) {
+      for (auto& pair : func->debugLocations) {


could you even do something like [_, location] here instead of having to use pair.second?

Co-authored-by: Alon Zakai <alonzakai@gmail.com>

Co-authored-by: Derek Schuff <dschuff@chromium.org>

kripken · 2025-12-05T15:44:59Z

CI error might be fixed eventually by #8094

This adds support for `names` field in source maps, which contains function names. Source map mappings are correspondingly updated and emsymbolizer now can provide function name information only with source maps. While source maps don't provide the full inlined hierarchies, this provides the name of the original (= pre-inlining) function, which may not exist in the final binary because they were inlined. This is because source maps are primarily intended for user debugging. This also demangles C++ function names using `llvm-cxxfilt`, so the printed names can be human-readable. I tested with `wasm-opt.wasm` from Binaryen by `if (EMSCRIPTEN)` setup here: https://github.com/WebAssembly/binaryen/blob/95b2cf0a4ab2386f099568c5c61a02163770af32/CMakeLists.txt#L311-L372 with `-g -gsource-map`. With this PR and WebAssembly/binaryen#8068, the source map file size increases by 3.5x (8632423 -> 30070042) primarily due to the function name strings. From `llvm-dwarfdump` output, this also requires additional parsing of `DW_TAG_subprogram` and `DW_TAG_inlined_subroutine` tags which can be at any depths (because functions can be within nested namespaces or classes), so we cannot use `--recurse-depth=0` (#9580) anymore. In case of `wasm-opt.wasm` built with DWARF info, without `--recurse-depth=0` in the command line, the size of its text output increased by 27.5x, but with the `--filter-child-tag` / `-t` option (llvm/llvm-project#165720), the text output increased only (?) by 3.2x, which I think is tolerable. This disables `names` field generation when `-t` option is not available in `llvm-dwarfdump` because it was added recently. To avoid this text size problem, we can consider using DWARF-parsing Python libraries like https://github.com/eliben/pyelftools, but this will make another third party dependency, so I'm not sure if it's worth it at this point. This also increased running time of `wasm-sourcemap.py`, in case of the `wasm-opt.wasm`, by 2.3x (6.6s -> 15.4s), but compared to the linking time this was not very noticeable. Fixes #20715 and closes #25116.

sbc100 · 2025-12-10T00:31:20Z

This change in combination with emscripten-core/emscripten#25870 seems to have broken emscripten testing.

WebAssembly#8068 failed to update `prologLocation` and `epilogLocation`, which caused the CI failure: https://app.circleci.com/pipelines/github/emscripten-core/emscripten/47832/workflows/ea0292aa-124d-4a3f-b988-0a96823e9bcd/jobs/1089017/tests This updates them properly.

#8068 failed to update `prologLocation` and `epilogLocation`, which caused the CI failure: https://app.circleci.com/pipelines/github/emscripten-core/emscripten/47832/workflows/ea0292aa-124d-4a3f-b988-0a96823e9bcd/jobs/1089017/tests This updates them properly.

This scans the code after optimizations and removes unused function names from 'names' field in the source map, reducing its size. Emscripten has not been generating 'names' field so far, but after emscripten-core/emscripten#25870, it will generate the field in case `llvm-dwarfdump` supports a new option `--filter-child-tag`.

WebAssembly#8068 failed to update `prologLocation` and `epilogLocation`, which caused the CI failure: https://app.circleci.com/pipelines/github/emscripten-core/emscripten/47832/workflows/ea0292aa-124d-4a3f-b988-0a96823e9bcd/jobs/1089017/tests This updates them properly.

This adds support for `names` field in source maps, which contains function names. Source map mappings are correspondingly updated and emsymbolizer now can provide function name information only with source maps. While source maps don't provide the full inlined hierarchies, this provides the name of the original (= pre-inlining) function, which may not exist in the final binary because they were inlined. This is because source maps are primarily intended for user debugging. This also demangles C++ function names using `llvm-cxxfilt`, so the printed names can be human-readable. I tested with `wasm-opt.wasm` from Binaryen by `if (EMSCRIPTEN)` setup here: https://github.com/WebAssembly/binaryen/blob/95b2cf0a4ab2386f099568c5c61a02163770af32/CMakeLists.txt#L311-L372 with `-g -gsource-map`. With this PR and WebAssembly/binaryen#8068, the source map file size increases by 3.5x (8632423 -> 30070042) primarily due to the function name strings. From `llvm-dwarfdump` output, this also requires additional parsing of `DW_TAG_subprogram` and `DW_TAG_inlined_subroutine` tags which can be at any depths (because functions can be within nested namespaces or classes), so we cannot use `--recurse-depth=0` (emscripten-core#9580) anymore. In case of `wasm-opt.wasm` built with DWARF info, without `--recurse-depth=0` in the command line, the size of its text output increased by 27.5x, but with the `--filter-child-tag` / `-t` option (llvm/llvm-project#165720), the text output increased only (?) by 3.2x, which I think is tolerable. This disables `names` field generation when `-t` option is not available in `llvm-dwarfdump` because it was added recently. To avoid this text size problem, we can consider using DWARF-parsing Python libraries like https://github.com/eliben/pyelftools, but this will make another third party dependency, so I'm not sure if it's worth it at this point. This also increased running time of `wasm-sourcemap.py`, in case of the `wasm-opt.wasm`, by 2.3x (6.6s -> 15.4s), but compared to the linking time this was not very noticeable. Fixes emscripten-core#20715 and closes emscripten-core#25116.

aheejin requested a review from dschuff November 26, 2025 01:21

aheejin mentioned this pull request Nov 26, 2025

Support names field in source maps emscripten-core/emscripten#25870

Merged

aheejin changed the title ~~Update 'names' field in source maps~~ Update names field in source maps Nov 26, 2025

kripken reviewed Dec 4, 2025

View reviewed changes

dschuff reviewed Dec 4, 2025

View reviewed changes

aheejin and others added 6 commits December 5, 2025 00:32

Merge branch 'main' into sourcemap_names_update

484554c

Update src/wasm/wasm-binary.cpp

f636186

Co-authored-by: Alon Zakai <alonzakai@gmail.com>

Use [_, location]

38d6742

Use [oldIndex, newIndex]

3a68a12

unordered_map -> map

93d135a

Add another test case to check determinism

a55a844

dschuff approved these changes Dec 5, 2025

View reviewed changes

Comment thread src/wasm/wasm-binary.cpp Outdated

aheejin and others added 2 commits December 4, 2025 23:36

Update src/wasm/wasm-binary.cpp

6a53061

Co-authored-by: Derek Schuff <dschuff@chromium.org>

Use [_, location]

d0a70ae

kripken approved these changes Dec 5, 2025

View reviewed changes

Merge branch 'main' into sourcemap_names_update

4845892

aheejin merged commit 93f40ae into WebAssembly:main Dec 9, 2025
17 checks passed

aheejin deleted the sourcemap_names_update branch December 9, 2025 01:32

aheejin mentioned this pull request Dec 10, 2025

Update source map names indices in prolog/epilog #8113

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update names field in source maps#8068

Update names field in source maps#8068
aheejin merged 10 commits into
WebAssembly:mainfrom
aheejin:sourcemap_names_update

aheejin commented Nov 26, 2025 •

edited

Loading

Uh oh!

aheejin commented Dec 4, 2025 •

edited

Loading

Uh oh!

kripken left a comment

Uh oh!

kripken Dec 4, 2025

Uh oh!

aheejin Dec 5, 2025

Uh oh!

Uh oh!

kripken Dec 4, 2025

Uh oh!

aheejin Dec 5, 2025

Uh oh!

dschuff Dec 4, 2025

Uh oh!

aheejin Dec 5, 2025 •

edited

Loading

Uh oh!

Uh oh!

kripken commented Dec 5, 2025

Uh oh!

Uh oh!

sbc100 commented Dec 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

aheejin commented Nov 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aheejin commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kripken left a comment

Choose a reason for hiding this comment

Uh oh!

kripken Dec 4, 2025

Choose a reason for hiding this comment

Uh oh!

aheejin Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kripken Dec 4, 2025

Choose a reason for hiding this comment

Uh oh!

aheejin Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

dschuff Dec 4, 2025

Choose a reason for hiding this comment

Uh oh!

aheejin Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kripken commented Dec 5, 2025

Uh oh!

Uh oh!

sbc100 commented Dec 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

aheejin commented Nov 26, 2025 •

edited

Loading

aheejin commented Dec 4, 2025 •

edited

Loading

aheejin Dec 5, 2025 •

edited

Loading