Replace mach dependency with mach2

[fitzgen]

Rebase of #6164 with added audit.

Fixes #6000
Fixes #6164
Fixes #8044

[bjorn3]

The region crate used by cranelift-jit still depends on mach.

[fitzgen]

That's fine, its not a dependency of wasmtime, and we can snip that dependency in a follow up PR if desired.

[bjorn3]

Looks like the region PR for moving to mach2 has been open for several months: darfink/region-rs#27 And worse the last release has been from over 2 years ago and once the current version gets released, it will lock the libc crate to version 0.2.107 from 2 years ago (for OpenBSD 6.9 support, which has been EOL since May 2022. libc presumably dropped support for it because it is EOL)

[cfallin]

Thanks!

[fitzgen]

@cfallin would you be up for fixing the aarch64 macOS build here? The last commit was too aggressive, and seems to have removed things that are still needed in mach2. The problem is I can't even do cargo check --target ... because I can't run the build scripts on my machine.

[cfallin]

I can take a look, sure.

[cfallin]

Pushed a fix; with this it cargo checks on macOS/aarch64. There's some weird inconsistency between the exception_behavior_t (a c_int) and the constants for the parameter (defined as c_uints); got a try_into/unwrap for now.

[cfallin]

Ah, but with that there is a panic at that unwrap during a cargo test. Looking further.

[cfallin]

OK, so the issue (one issue anyway) is that MACH_EXCEPTION_CODES is defined as 0x8000_0000, which works great for its u32 type, but not the i32 type behind exception_behavior_t. I had hoped this was just a C-ism and tried an as cast to YOLO the signedness; that now runs into a SIGABRT on cargo test. This is officially Above My macOS Knowledge and needs someone else to look at it, I think!

[alexcrichton]

Testing locally I'm seeing something that looks like it's running into this comment, namely the bindings for __Request__exception_raise_t are not aligned. I don't know if the bindings are right or what's going on here, but I vaguely remember seeing in the past another project define the type locally and use 64-bit values as well.

[alexcrichton]

Notably the mach2 crate uses integer_t there, which is i32, not i64.

[alexcrichton]

I've pushed a commit which passes tests locally by copying over the copy of the struct that we have today and additionally queues up all tests to run in CI.