Stream: git-wasmtime

Topic: wasmtime / issue #2684 Source Maps to Aid Debuggability?


view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 16:37):

alexcrichton commented on issue #2684:

I'm going to close this since I think we're pretty unlikely to implement source maps literally. Instead backtraces today already have filenames and line numbers and there's also DWARF info support too.

view this post on Zulip Wasmtime GitHub notifications bot (May 05 2022 at 16:37):

alexcrichton closed issue #2684:

Feature

Source maps, to help us debug WASM modules that were written in another language.

That is, it'd be great if WASM errors told us on what line and in what file an exception was thrown _in the original source code_ before it was compiled to WASM.

Benefit

Debuggability. I'm worried that the dream of making WASM the ultimate cross-language compatibility layer will die if debugging our apps remains significantly harder after compiling them to WASM than before. Automatic (though optional) generation of a source map file seems like one reasonable way to solve this problem.

Implementation

I am imagining a file that is generated when the initial $language-to-WASM compilation occurs that maps error strings in the program (that remain in the WASM version) to file names and line numbers in the original source files, or similar. Then, when an error occurs and the source map file (just described) is present, perhaps the stack trace shown could contain code or at least line numbers from the original source so that it's easier to figure out where _in the original program_ the bug lies.

Alternatives

The source map could potentially be built into the compiled WASM module itself, kind of like an unstripped binary, rather then being a separate file, but this would monkey with the WASM file format so I assume you folks won't like that version as much.


Last updated: Dec 23 2024 at 13:07 UTC