wasm: support source maps for the unknown target

[rpjohnst]

Quoting #46765, which was closed and locked inexplicably:

Source maps are the analogon to debuginfo in the js world, including wasm. So we should generate them.

Emscripten apparently already is able to emit them, at least this example contains source maps: https://yurydelendik.github.io/old-man-sandbox/rust-wasm-hey/hey.html Maybe it's not upstreamed yet, idk.

I guess the bulk of this work would reside inside llvm, but I'm still filing a bug here to track support.

[CryZe]

There was brief support for them when the unknown target used binaryen as the linker, but with the switch to LLD the support was lost. However as far as I know the long term goal is to have proper debuginfo support (via a web version of DWARF) for WebAssembly. I'm pretty sure source maps were just a short term solution.

[newpavlov]

Are source maps part of WebAssembly standard? If not, then I think we should not add them for wasm32-unknown-unknown target and instead introduce them only for wasm32-web-unknown.

[MaulingMonkey]

Are source maps part of WebAssembly?

Not yet. Current state of things:

• It's listed under "Proposals we might consider in the future" here: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#source-maps-integration
• There's an open pull request / discussion here dating back to May 2017: Source maps applied to wasm binaries WebAssembly/design#1051
• FireFox has support for WebAssembly referencing source maps.

I made a brief attempt to use wasm-dwarf on a wasm32-unknown-unknown library. After much wailing and gnashing of teeth, I was finally able to get things briefly "working". It mapped my callstack to entirely the wrong functions not sharing common disassembly (I'm not sure if that's a wasm-dwarf bug, or a rust bug, or if dwarf info for wasm32-unknown-unknown is currently meaningless by design) and seems to be extremely tempermental - I can't even step into WASM functions from JS without hanging the debugger at the moment (FireFox Bug?), despite my demo running fine when told to simply continue execution instead, and having successfully done so previously.

My current script (creating a second modified *_dbg.wasm + .map) in case it proves useful to someone else trying to take this further:

@set NAME=rust_wasm_sample
cargo build --target=wasm32-unknown-unknown
wasm-dwarf ^
       target/wasm32-unknown-unknown/debug/%NAME%.wasm ^
    -p /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/=file://C:/Users/%USERNAME%/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust/ ^
    -p /cargo/registry/=file://C:/Users/%USERNAME%/.cargo/registry/ ^
    -p src/liballoc/=file://C:/Users/%USERNAME%/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust/src/liballoc/ ^
    -p src/libcore/=file://C:/Users/%USERNAME%/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust/src/libcore/ ^
    -p src/libstd/=file://C:/Users/%USERNAME%/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust/src/libstd/ ^
    -p src/libpanic_abort/=file://C:/Users/%USERNAME%/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust/src/libpanic_abort/ ^
    -p src/=../../../src/ ^
    -w target/wasm32-unknown-unknown/debug/%NAME%_dbg.wasm ^
    -o target/wasm32-unknown-unknown/debug/%NAME%_dbg.wasm.map ^
    -m %NAME%_dbg.wasm.map

[alexcrichton]

I'm going to close this because tooling for wasm is generally moving towards DWARF nowadays which is supported by rustc. There's some tools in the ecosystem (I think) to convert DWARF to source maps, which should be used if source maps are desired.