Wasmtime GitHub notifications bot (Apr 06 2021 at 13:56): Wasmtime GitHub notifications bot (Apr 06 2021 at 13:56):bnjbvr opened Issue #2808:
On Mac aarch64 (e.g. M1 MBP), the system's libunwind doesn't behave as on other platforms, and doesn't properly unwind wasm frames using the information we provide it (CFI etc.). The PR that introduces the switch from using signal handlers to mach ports to handle software traps has something that worked, using a custom build of libunwind and custom directives for linking against it.
Some ways to fix this:
- poke more at the system's libunwind, to try to understand what it wants. At some point its source code might be released on https://opensource.apple.com/, and if we can reproduce the issues observed with the system's libunwind, then we could investigate them with a debugger.
- I've had some discussions with Apple engineers who said these particular functions were not particularly used and tested by Apple. So we could look into other functions exposed by libunwind and try to use those instead. This would be pretty invasive, since that would require coordination with
backtrace-rstoo, which uses libunwind's functions as well.- ship a custom build of libunwind, and link against it. I don't know
backtrace-rswould also require the custom link annotations.- implement our own frame unwinder (after all, we don't need a lot), or find another existing implementation that works equally well. There was some talk on the Rust's zulip to reimplement libunwind in Rust at some point, I don't know what came out of that.
Wasmtime GitHub notifications bot (Apr 06 2021 at 13:56):bnjbvr labeled Issue #2808:
On Mac aarch64 (e.g. M1 MBP), the system's libunwind doesn't behave as on other platforms, and doesn't properly unwind wasm frames using the information we provide it (CFI etc.). The PR that introduces the switch from using signal handlers to mach ports to handle software traps has something that worked, using a custom build of libunwind and custom directives for linking against it.
Some ways to fix this:
- poke more at the system's libunwind, to try to understand what it wants. At some point its source code might be released on https://opensource.apple.com/, and if we can reproduce the issues observed with the system's libunwind, then we could investigate them with a debugger.
- I've had some discussions with Apple engineers who said these particular functions were not particularly used and tested by Apple. So we could look into other functions exposed by libunwind and try to use those instead. This would be pretty invasive, since that would require coordination with
backtrace-rstoo, which uses libunwind's functions as well.- ship a custom build of libunwind, and link against it. I don't know
backtrace-rswould also require the custom link annotations.- implement our own frame unwinder (after all, we don't need a lot), or find another existing implementation that works equally well. There was some talk on the Rust's zulip to reimplement libunwind in Rust at some point, I don't know what came out of that.
Wasmtime GitHub notifications bot (Apr 06 2021 at 16:35):fitzgen commented on Issue #2808:
Related: https://github.com/bytecodealliance/wasmtime/issues/2459
Last updated: Nov 22 2024 at 17:03 UTC