Wasmtime GitHub notifications bot (Mar 12 2021 at 17:51): Wasmtime GitHub notifications bot (Mar 12 2021 at 17:51):github-actions[bot] commented on Issue #2723:
Subscribe to Label Action
cc @peterhuene
<details>
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "wasmtime:api"Thus the following users have been cc'd because of the following labels:
- peterhuene: wasmtime:api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Mar 15 2021 at 15:49):bnjbvr commented on Issue #2723:
I'm hitting this in CI and I've got no clue how to get around it:
E: The repository 'https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_18.04 Release' no longer has a Release file.
Wasmtime GitHub notifications bot (Mar 16 2021 at 13:55):bnjbvr commented on Issue #2723:
Thanks for the reviews! This will require a review of https://github.com/fitzgen/mach/pull/64, which I can incorporate in this PR, if it's simpler -- would be nice to have the code be in the right places, though :)
Wasmtime GitHub notifications bot (Mar 17 2021 at 09:34):bnjbvr commented on Issue #2723:
Now not depending on the Mach PR anymore; should make the verify CI task happy!
Wasmtime GitHub notifications bot (Mar 17 2021 at 14:10):alexcrichton commented on Issue #2723:
To confirm, am I correct in understanding that this PR now serves two purposes and is reading for landing:
- First it fixes the combination of wasmtime and breakpad on macOS by using mach ports for exceptions instead of signal handlers.
- Second it adds a small bit of support for AArch64 mac machines to the point where we can "catch" wasm traps but the backtraces are incorrect. (maybe only one frame of wasm instead of all the frames)
Does that sound right? If so seems reasonable to me to land!
Wasmtime GitHub notifications bot (Mar 17 2021 at 14:20):bnjbvr commented on Issue #2723:
Yes, this is entirely correct! MacOS CI passing suggests that the backtraces are still properly filled (i.e. contain all the frames) on darwin x86_64.
One note for readers: it's possible to get all the frames in backtrace by using a custom build of libunwind:
- clone and build libunwind from LLVM's repository. Say
/tmp/libunwind_build/contains the build artifacts.- in crates/jit/src/unwind/system.rs, add
#[link(lib = "unwind", kind = "static")]on top of theextern "C"block that defines__register_frame.- build with
RUSTFLAGS="-L /tmp/libunwind_build/" cargo buildThis is sufficient to get all the frames appearing on backtraces on mac aarch64.
Wasmtime GitHub notifications bot (Mar 17 2021 at 14:43):alexcrichton commented on Issue #2723:
Ok! Let's go ahead and land this to get to a more working state along those two points, and we can figure out later how to best handle the unwinding intricacies on macOS AArch64
Wasmtime GitHub notifications bot (Apr 06 2021 at 13:48):bnjbvr edited a comment on Issue #2723:
Yes, this is entirely correct! MacOS CI passing suggests that the backtraces are still properly filled (i.e. contain all the frames) on darwin x86_64.
One note for readers: it's possible to get all the frames in backtrace by using a custom build of libunwind:
- clone and build libunwind from LLVM's repository. Say
/tmp/libunwind_build/contains the build artifacts.- in crates/jit/src/unwind/system.rs, add
#[link(name = "unwind", kind = "static")]on top of theextern "C"block that defines__register_frame.- build with
RUSTFLAGS="-L /tmp/libunwind_build/" cargo buildThis is sufficient to get all the frames appearing on backtraces on mac aarch64.
Last updated: Oct 23 2024 at 20:03 UTC