You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a large work item so I am splitting it from #2169.
What we have today:
On browser:
We capture the full stack trace via a JS API when the exception is thrown
We minimally "demangle" the mangled names that are written into the "names" section. This demangling procedure is not precise.
On WASI:
We have nothing except the raw "unmanaged" stack trace from traps generated when an unhandled exception occurs. This is because WASI lacks APIs that would allow us to access the stack (see also stack trace API WebAssembly/WASI#159).
The mangled names have so far been an acceptable stop-gap solution, but we can and should do better. The ultimate goal is parity with the implementation on non-WASM targets.
Here's a rough outline of the strategy that would work for the browser targets:
Create a WASM object writer that is capable of producing object files with R_WASM_FUNCTION_OFFSET family of relocations. This is needed because LLVM does not support emitting them for the data section. Verify first that the linker is able to process them, however.
Emit the upstream stack trace metadata blob using this object writer and function offsets as "RVA"s.
Modify runtime code to extract WASM code offsets from the stack trace and use them much like the normal runtime would use RVAs.
Think about what (if anything) needs to be done for the ExceptionDispatchInfo functionality to be complete.
WASI is harder... We could push for a stack trace API to be added upstream (for the second time); I think I could create a prototype for Wasmtime, but it would be anyone's guess when and if that goes through.
We can utilize the virtual unwind stack to capture stack traces, by linking all frames and disabling some optimizations, and that would work for Debug builds, but not for Release ones due to the overhead. Of course, stack traces in Debug is better than the current state of "nothing", but it would be much, much better if we could utilize the same approach as for browsers.
The text was updated successfully, but these errors were encountered:
WASI is harder... We could push for a stack trace API to be added upstream (for the second time); I think I could create a prototype for Wasmtime, but it would be anyone's guess when and if that goes through.
Treat native WASM frames as JS frames (or use names from the names section for them). This is a nice-to-have; not required for parity with other targets.
This is a large work item so I am splitting it from #2169.
What we have today:
The mangled names have so far been an acceptable stop-gap solution, but we can and should do better. The ultimate goal is parity with the implementation on non-WASM targets.
Here's a rough outline of the strategy that would work for the browser targets:
R_WASM_FUNCTION_OFFSET
family of relocations. This is needed because LLVM does not support emitting them for the data section. Verify first that the linker is able to process them, however.ExceptionDispatchInfo
functionality to be complete.WASI is harder... We could push for a stack trace API to be added upstream (for the second time); I think I could create a prototype for Wasmtime, but it would be anyone's guess when and if that goes through.
We can utilize the virtual unwind stack to capture stack traces, by linking all frames and disabling some optimizations, and that would work for Debug builds, but not for Release ones due to the overhead. Of course, stack traces in Debug is better than the current state of "nothing", but it would be much, much better if we could utilize the same approach as for browsers.
The text was updated successfully, but these errors were encountered: