Wasmtime GitHub notifications bot (Feb 24 2021 at 00:04): Wasmtime GitHub notifications bot (Feb 24 2021 at 00:04):elimisteve opened 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.
Wasmtime GitHub notifications bot (Feb 24 2021 at 02:30):alexcrichton commented on Issue #2684:
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!
Wasmtime GitHub notifications bot (Feb 26 2021 at 01:12):elimisteve commented on Issue #2684:
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: https://github.com/WebAssembly/wasi-sdk/issues/174
Wasmtime GitHub notifications bot (Feb 26 2021 at 15:29):alexcrichton commented on Issue #2684:
AFAIK it's the typical debuginfo flags in clang, e.g.
-g, that generates DWARF info.
Wasmtime GitHub notifications bot (Feb 26 2021 at 21:25):yurydelendik commented on Issue #2684:
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.
Last updated: Nov 22 2024 at 16:03 UTC