Backtrace with SourceSpan

[oovm]

Is it possible to append source span information to generate a backtrace that jumps to the source language?

Assume the following syntax:

(func $source-function
    (result i32)
    (i32.const 0)
    (@name "package::module::function-name")
    (@file "language-source.file") ;; or shared source id, the path will appear multiple times
    (@line 12) (@column 4)         ;; if source is utf8 text file, use line and utf8 width
    (@offset 114)                  ;; if not a text file or non-utf8 encoding
)

Then the following log will be generated during trap, and the IDE can recognize and generate a local link:

0: 0x00000100 - unreachable or other trap name
1: 0x00000104 - in package::module::function-name(input1, input2)
                at language-source.file:114
2: 0x00000108 - in package::module::function-caller(input1, input2, input3)
                at language-source.file:514

---

It seems that the browser can use source-map or DWARF, but this is not part of the wasm standard, and it does not fit the features of wasm very well.

Should the wasm standard define a standardized set of debugger metainfo?

[dschuff]

I think there hasn't been too much appetite for this (i.e. a standardized way to specify source-mapping information) so far mostly because source maps and DWARF have worked well enough. It's not completely ideal, and there are some known deficiencies (e.g. the fact that sourcemap's line/column format doesn't map perfectly to wasm's binary format, and the fact that DWARF can't currently assign source information to constant initializers), but it works well enough for many use cases.

I think it would be pretty straightforward to document a text syntax something like your example using the annotations proposal, and perhaps a binary equivalent using the compilation hints proposal. It could be useful for use cases where DWARF or sourcemaps aren't a good fit, but it would be unlikely to replace them for cases where they are already used. It wouldn't need to go through the full formal process to be useful; it could end up as a document in the tool-conventions.

[fitzgen]

Another tricky bit is that the debug info can be split out from the debuggee artifact and might require e.g. fetching the debug info over the network.

In the context of a JS embedding of Wasm, does this mean that the trap (and the associated JS error message) should block on that network request? Or would it be nondeterministic whether you get Wasm-level information or source-level information? Or would there be a new method that returns a promise of an error message with source-level information?

[oovm]

There seems to be no tool that can debug at the wat level. If you switch to wasm, all redundant information will be erased and the source location will also need to be remapped.

[kripken]

@oovm I'm not sure what you mean by "debug at the wat level", but binaryen has support for source annotations in wat files using JS-style //@ FILE:LINE:COL. For example

;;@ src.cpp:200:2
(local.set $temp
  ..
)

That means that local.set is from src.cpp at line 200 and column 2. Example test:

https://github.com/WebAssembly/binaryen/blob/b671b6ce2ccbff5e1b735293bcf7fe94a5b65971/test/lit/debug/replace-keep.wat#L61-L70

Those are equivalent to source maps, but can be embedded in the wat.