stack trace API

[tlively]

Many applications need stack traces for proper logging and debugging support, but due to WebAssembly's Harvard architecture and structured control flow, it is impossible to implement stack traces in WebAssembly without help from the embedder.

Emscripten has a bespoke stack trace API that parses and caches JS stack traces, but that is not usable outside a JS embedding, so it would make sense to standardize a WASI API for stack traces that all embedders can implement. Stack traces give WebAssembly modules introspection capabilities they would not otherwise have, so the API should require a capability.

[pchickey]

This sounds useful. We are working on support for stack traces to Lucet right now. I'm not super familiar with that functionality in emscripten, can you provide a link to the implementation?

[KronicDeth]

WebAssembly/debugging#5 overlaps with this.

[tlively]

Emscripten's implementation can be found at https://github.com/emscripten-core/emscripten/blob/7e93e0398b0c761d5f16ee507ad13016a9503443/src/library.js#L4275-L4487

[tlively]

LLVM also knows how to automatically convert __builtin_return_address() in C/C++ into a call to emscripten_return_address when targeting Emscripten specifically[0]. Having a WASI API for this would allow us to extend support for __builtin_return_address() to non-emscripten targets.

[0] https://github.com/llvm/llvm-project/blob/cfce8f2cfba42edd3eb49e6b6484d60fb6aeeb43/llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp#L280-L283

[sunfishcode]

This sounds useful to me too. A few questions that occur to me at first glance:

Is the stack trace expected to be deterministic, in the presence of inlining or other optimizations?

Should we expect all wasm engines to implement it? Or perhaps all engines which implement wasm EH? We can definitely put it in its own module and make it feature-testable with optional imports, but the question will come in LLVM -- should LLVM import the module unconditionally, or dynamically test for it?

Would it makes sense to make __builtin_extract_return_addr return an error, as a way of drawing a line in the sand? This would reflect how the thing __builtin_return_address returns isn't an actual address -- you can interpret it if you know how wasm works, but you can't convert it to a code address.

[devsnek]

JS is working on a way to hide functions from stack traces for security reasons. Would we want to consider similar functionality?

[KronicDeth]

Erlang and Elixir are used to stack traces being “incomplete” because all tail calls under go tail call optimizations, so we don’t have any objection to hiding calls for security or other reasons. I’d prefer it over and JDK situation where stack traces were spec’d as having to have all calls, which made Clojure and JRuby messier.

[tlively]

Is the stack trace expected to be deterministic, in the presence of inlining or other optimizations?

Do you mean inlining and optimizations performed by the engine? I don't have much of an opinion on that because I'm not super familiar with the relevant tradeoffs. I would not expect the stack trace to be preserved across optimizations performed by toolchains, though, so this is a question for engine implementors rather than language implementors.

Should we expect all wasm engines to implement it?

I think this would be reasonable. I assume all production engines today have some way of reporting the location of a trap, and this would be similar.

Would it makes sense to make __builtin_extract_return_addr return an error, as a way of drawing a line in the sand? This would reflect how the thing __builtin_return_address returns isn't an actual address -- you can interpret it if you know how wasm works, but you can't convert it to a code address.

Yes, that sounds fine to me.

[linclark]

Discussing with @sunfishcode, we're thinking this is more of a core VM feature than a WASI issue. It also seems like work in the core CG (e.g. around unwinding and stack switching) is reasonably likely to lead to a stack trace debugging mechanism, so I'm going to close this one for now.