Chris Fallin

Hi @srenatus -- yes, ideally we'll eventually be able to add a build/test CI job for macOS/aarch64, but unfortunately GitHub Actions doesn't currently support the platform, so we're blocked on...

Hi @anistark -- unfortunately the situation with GitHub CI support for macOS on aarch64 (M1) is still the same, i.e. there is none. The issue actions/virtual-environments#2187 seems to be tracking...

@HowJMay we do use qemu for Linux/aarch64, and it works great for that! That's why we're able to have Linux/aarch64 binaries even though GitHub CI doesn't natively support aarch64. Unfortunately...

From a technical standpoint that would work but in the past we've avoided self-hosting runners due to the associated [security concerns](https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security). It looks like in the issue related to GitHub-hosted...

One further thought on security: I think we could *potentially* accept a selfhosted runner (with proper isolation) giving us test results on macos-aarch64, but we should absolutely remain on GitHub-hosted...

I don't think there's any conflict, given cross-compilation? Ah, so actually, taking a step back, I'm not sure if latest context with `wasmtime` proper has been incorporated here: we *do*...

@adv-sw the bug described here can occur even without using the C API, so it doesn't make sense that a change in the `c-api` crate would have caused it. Can...

@SingleAccretion that seems like a plausible explanation -- it's entirely possible that we missed a debug-info update when chomping branches. Would you be willing to make an attempt at fixing...

The disassembly bit is intentional: it's meant to be a dump of the VCode, which stays in N-target branch form, rather than an exact correspondence to the machine code. VCode...

@abrown are you interested in pursuing this further? (Going through old PRs and cleaning up...) I agree with @bjorn3 that the alignment issue is the critical question here, and so...