Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NativeAOT-LLVM] Implement managed stack traces #2404

Open
SingleAccretion opened this issue Sep 16, 2023 · 1 comment
Open

[NativeAOT-LLVM] Implement managed stack traces #2404

SingleAccretion opened this issue Sep 16, 2023 · 1 comment
Labels
area-NativeAOT-LLVM LLVM generation for Native AOT compilation (including Web Assembly)

Comments

@SingleAccretion
Copy link

This is a large work item so I am splitting it from #2169.

What we have today:

  1. 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.
  2. 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:

  1. 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.
  2. Emit the upstream stack trace metadata blob using this object writer and function offsets as "RVA"s.
  3. Modify runtime code to extract WASM code offsets from the stack trace and use them much like the normal runtime would use RVAs.
  4. 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.

@jkotas jkotas added the area-NativeAOT-LLVM LLVM generation for Native AOT compilation (including Web Assembly) label Sep 16, 2023
@yowl
Copy link
Contributor

yowl commented Dec 13, 2023

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.

Maybe relevant: WebAssembly/wasi-sdk#334 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-NativeAOT-LLVM LLVM generation for Native AOT compilation (including Web Assembly)
Projects
None yet
Development

No branches or pull requests

3 participants