Repository navigation
Add --enable-source-map support for WebAssembly module #46873
Description
Activity
- addedfeature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Feb 27, 2023 Initial support for JS source maps was added in #29564, but as far as I can tell the
sourceMappingURLsection of wasm files is not yet being honored.To build a wasm file with source map support in emscripten you can do
emcc -gsource-map hello.c.Here is an example that I used to test:
#include <stdio.h> int main() { printf("hello, world!\n"); __builtin_trap(); return 0; } $ ./emcc test/hello_world.c -gsource-map $ $ node --enable-source-maps ./a.out.js hello, world! /usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:131 throw ex; ^ RuntimeError: unreachable at __original_main (wasm://wasm/073677ae:wasm-function[3]:0x2af) at main (wasm://wasm/073677ae:wasm-function[4]:0x2b5) at /usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:929:22 at callMain (/usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:1706:15) at doRun (/usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:1756:23) at run (/usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:1771:5) at runCaller (/usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:1691:19) at removeRunDependency (/usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:838:7) at receiveInstance (/usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:1072:5) at receiveInstantiationResult (/usr/local/google/home/sbc/dev/wasm/emscripten/a.out.js:1091:5) Node.js v19.0.0 $ wasm-objdump -s -j sourceMappingURL a.out.wasm a.out.wasm: file format wasm 0x1 Contents of section Custom: 00032ff: 1073 6f75 7263 654d 6170 7069 6e67 5552 .sourceMappingUR 000330f: 4c0e 612e 6f75 742e 7761 736d 2e6d 6170 L.a.out.wasm.map@bcoe who originally added the --enable-source-maps option
- addedwasmIssues and PRs related to WebAssembly.Issues and PRs related to WebAssembly.
on Feb 28, 2023 I believe @bcoe isn't actively involved anymore.
Pull request welcome. Node needs to call
isolate->SetWasmLoadSourceMapCallback(callback)and the callback should return the source map as aLocal<String>.Reacted by Debadree ChatterjeeIf I understand correctly we are supposed to make a call to
isolate->SetWasmLoadSourceMapCallback(callback)function somewhere around here? @bnoordhuis
Lines 1270 to 1279 in f94ef7c
if (result->Set(parsing_context, env->cache_key_string(), cache_key) .IsNothing()) return; if (result ->Set(parsing_context, env->source_map_url_string(), fn->GetScriptOrigin().SourceMapUrl()) .IsNothing()) return; That's for the
vmmodule. For general use, I'd add it inSetIsolateMiscHandlers()in src/api/environment.cc.Reacted by Debadree ChatterjeeI tried something like this
diff --git a/src/api/environment.cc b/src/api/environment.cc index f56ee8d12b..c73a47a35a 100644 --- a/src/api/environment.cc +++ b/src/api/environment.cc @@ -260,6 +260,11 @@ void SetIsolateErrorHandlers(v8::Isolate* isolate, const IsolateSettings& s) { } } +Local<String> WASMLoadSourceMapCb(Isolate* isolate, const char* path) { + std::cout << "WASMLoadSourceMapCb" << std::endl; + return String::Empty(isolate); +} + void SetIsolateMiscHandlers(v8::Isolate* isolate, const IsolateSettings& s) { isolate->SetMicrotasksPolicy(s.policy); @@ -267,6 +272,10 @@ void SetIsolateMiscHandlers(v8::Isolate* isolate, const IsolateSettings& s) { s.allow_wasm_code_generation_callback : AllowWasmCodeGenerationCallback; isolate->SetAllowWasmCodeGenerationCallback(allow_wasm_codegen_cb); + auto* wasm_load_source_map_callback = s.wasm_load_source_map_callback ? + s.wasm_load_source_map_callback : WASMLoadSourceMapCb; + isolate->SetWasmLoadSourceMapCallback(wasm_load_source_map_callback); + auto* modify_code_generation_from_strings_callback = ModifyCodeGenerationFromStrings; if (s.modify_code_generation_from_strings_callback != nullptr) { diff --git a/src/node.h b/src/node.h index fc2531f867..3e8003b820 100644 --- a/src/node.h +++ b/src/node.h @@ -483,6 +483,7 @@ struct IsolateSettings { allow_wasm_code_generation_callback = nullptr; v8::ModifyCodeGenerationFromStringsCallback2 modify_code_generation_from_strings_callback = nullptr; + v8::WasmLoadSourceMapCallback wasm_load_source_map_callback = nullptr; }; // Represents a startup snapshot blob, e.g. created by passing
just to test, it seems the callback is never called, I tried searching for any docs on
SetWasmLoadSourceMapCallbackbut nothing useful found, hence asking here 😅😅On closer inspection it looks like V8 currently supports source maps only for profiling, not for exception stack traces.
Your change would improve the usability of e.g. the
--perf-basic-profflag.Reacted by Debadree Chatterjee- added a commit that references this issue
on Mar 10, 2023 I tried experimenting with loading source maps for profiling here debadree25@60ead86 it seems the callbacks are correctly called and loaded but I don't seem to find much of a difference between flamegraphs created when profiling because I am able to see the C function in both of them so quite confusing 😅
WASM files can contain DWARF debug data. V8 uses it if there's no sourcemap available.
Reacted by Debadree ChatterjeeUnderstood, thank you so much for explaining it seems emscripten automatically adds the DWARF info when building with
-gsource-mapso won't make much of a difference to enable this feature for profiling will try to pick this up when v8 enables having this for error stack traces11 remaining items
- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Sep 30, 2023 Was reading through the v8 code surrounding this found the following comment
node/deps/v8/src/wasm/wasm-module-sourcemap.cc
Lines 144 to 145 in cce5a8c
// Column number in source file is always 0 in source map generated by // Emscripten. We just decode this value without further usage of it. does the comment still hold true? and could this be the reason why are not seeing the code positions, apprently this is just about columns
Even if the column number is always zero I would still expect to see filename and line number.
- removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Oct 2, 2023 github-actions commented
on Mar 31, 2024 on Mar 31, 2024 – with GitHub ActionsContributorMore actionsThere has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
- addedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Mar 31, 2024 There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.
Has this feature been implemented?
Reopening this as the use case remains.
Reacted by Jay Phelps- addednever-staleIssues and PRs exempt from automated stale handling.Issues and PRs exempt from automated stale handling.and removedstaleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.
on Feb 22, 2025
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsAwaiting Triage
What is the problem this feature will solve?
I will allow developers to get better backtrace information from wasm module that are built with source maps.
What is the feature you are proposing to solve the problem?
Reading of the sourceMappingURL section from any WebAssembly modules that get loaded.
What alternatives have you considered?
No response