Source Maps to Aid Debuggability?

[elimisteve]

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.

[alexcrichton]

Thanks for the report! Out of curiosity, do you have a language that compiles to WebAssembly with source maps in mind already?

For Rust/C/C++ Wasmtime already supports this feature with DWARF debug information:

$ cat foo.rs
fn main() {
    panic!("hello");
}
$ rustc foo.rs --target wasm32-wasi -g
$ wasmtime foo.wasm
...
           6: 0x1153 - <unknown>!foo::main::h2db1313a64510850
...
       note: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information
$ export WASMTIME_BACKTRACE_DETAILS=1
$ wasmtime foo.wasm
...
           6: 0x1153 - foo::main::h2db1313a64510850
                           at /path/to/foo.rs:2:5
...

and the API provides this information through FrameInfo::symbols.

Wasmtime doesn't currently support source maps but that's not because we don't want to, it's just because no one's gotten to it yet!

[elimisteve]

Out of curiosity, do you have a language that compiles to WebAssembly with source maps in mind already?

I do! A language that compiles to C, namely V, so from wasmtime's perspective it's just normal C code I'm compiling. How should I tell WASI-enabled clang to have the resulting .wasm file include DWARF debug info? (Thanks!)

More broadly, unfortunately I couldn't get my C code code to compile with wasi-sdk-12 due to

$ clang cp-skip-unused.c -o demo.wasm
In file included from cp-skip-unused.c:171:
/opt/wasi-sdk/share/wasi-sysroot/include/signal.h:2:2: error: "wasm lacks signal support; to enable minimal signal emulation, compile with -D_WASI_EMULATED_SIGNAL and link with -lwasi-emulated-signal"
#error "wasm lacks signal support; to enable minimal signal emulation, \
 ^
cp-skip-unused.c:351:11: fatal error: 'pthread.h' file not found
        #include <pthread.h>
                 ^~~~~~~~~~~
2 errors generated.

and didn't know what needed to be recompiled nor which compiler I needed to pass those flags to.

I just created an issue for this: WebAssembly/wasi-sdk#174

[alexcrichton]

AFAIK it's the typical debuginfo flags in clang, e.g. -g, that generates DWARF info.

[yurydelendik]

How should I tell WASI-enabled clang to have the resulting .wasm file include DWARF debug info?

wasi-sdk/llvm's "llvm-dwarfdump" allows to inspect wasm files DWARF sections too.

[alexcrichton]

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.