iOS target support #7506

jmp-0x7C0 · 2023-11-08T21:54:12Z

As discussed with @alexcrichton on zulip, there appears to be some interest in supporting iOS as a platform. This PR makes the necessary changes for wasmtime to build when targeting aarch64-apple-ios.

A few notes about this PR:

Although it is now possible to compile wasmtime for the iOS target, being able to run *.cwasm modules is not yet possible. From what @alexcrichton explained to me it appears there would be some additional work would be needed
to postprocess a *.cwasm file into a linkable object files before this can be used in an iOS application. I would be interested in taking on this future work however my understanding of what this would involve is still very limited and I would need help sketching this out in detail.
I haven't yet tested anything beyond making sure that the cargo check passes. If there are any suggestions of what might be useful to test at this stage before merging this I'd be happy to add in CI tests or do any manual testing deemed appropriate.
With limited knowledge about the differences between iOS and macOS I am assuming that macOS is identical to iOS for the purposes of this PR, e.g. I have no idea if the whole mach ports vs signals question makes sense for iOS.
I made the minimal set of changes to get the code compiling, before merging the PR it might make sense to rename certain things e.g. it might make sense to rename the macos module in the runtime crate to apple or similar.

As this is the first time contributing, please let me know if this PR makes sense or would need any changes to align with the contributing guidelines for this project.

alexcrichton

Thanks for this! If you're ok with it though because this is a pretty small patch I'd personally recommend not merging this just yet and moving on to the next steps of trying to get code running (if you're interested in doing those next steps). I'm a bit worried about how there's a number of open questions and I find it easier to remember the questions if they're highlighted in a diff here rather than hunting around a preexisting codebase.

If you'd prefer though I also think it'd be reasonable to land ahead of time.

One suggestion I'd have is that you can probably void updating any tests at this time. I think we're probably still aways out from running tests on iOS so I think it'd be ok to cross that bridge when we get there.

alexcrichton · 2023-11-08T22:05:54Z

cranelift/native/src/lib.rs

@@ -115,7 +115,7 @@ pub fn infer_native_flags(isa_builder: &mut dyn Configurable) -> Result<(), &'st
            isa_builder.enable("has_pauth").unwrap();
        }

-        if cfg!(target_os = "macos") {
+        if cfg!(any(target_os = "macos", target_os = "ios")) {


This is something that I think may need to be confirmed. The comment below for example is incorrect since not all iOS devices will run on Apple Silicon, but I'm sure all recent ones do. That being said I don't know the story for return-address-signing on iOS and whether or not it's different than macOS.

alexcrichton · 2023-11-08T22:06:57Z

cranelift/native/src/lib.rs

+            if cfg!(all(
+                any(target_os = "macos", target_os = "ios"),
+                target_arch = "aarch64"
+            )) {


This is also something to watch out for once you're at the point you can run some code. This block is true for macOS but iOS may very well be different in its calling convention. I'm not sure either way (or where to look it up), so it's mostly something to watch out for to see if apps crash when you load them.

From what I can see from https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms, it doesn't look like macOS and iOS have different calling conventions on arm64.

alexcrichton · 2023-11-08T22:07:36Z

crates/fiber/src/unix/aarch64.rs

@@ -22,7 +22,7 @@ use super::wasmtime_fiber_start;
 use wasmtime_asm_macros::asm_func;

 cfg_if::cfg_if! {
-    if #[cfg(target_os = "macos")] {
+    if #[cfg(any(target_os = "macos", target_os = "ios"))] {


This relates to my comment about pointer authentication above, because if iOS uses the A key instead of the B key then this block would need to change.

Looking at https://support.apple.com/en-ng/guide/security/sec8b776536b/1/web/1#sec0167b469d, there does not seem to be any indication there are any differences across iOS and macOS regarding which key is used, it always seems to be IB for return addresses.

alexcrichton · 2023-11-08T22:13:59Z

crates/runtime/src/traphandlers/unix.rs

@@ -178,7 +178,7 @@ unsafe extern "C" fn trap_handler(
 // more accurate definition. When that PR and/or issue is resolved then this
 // should no longer be necessary.
 #[repr(C)]
-#[cfg(all(target_arch = "aarch64", target_os = "macos"))]
+#[cfg(all(target_arch = "aarch64", any(target_os = "macos", target_os = "ios")))]


If possible you'll want to use libc::ucontext_t instead of this. This structure is one that has a high risk of being different between iOS and macOS. I posted #7507 to remove this structure definition entirely as it's not longer necessary (the PR referenced in the above comment has landed and has been published). I think you should be able to use libc::ucontext_t for iOS, but that depends on the libc crate which I can't say with certainty.

alexcrichton · 2023-11-08T22:21:32Z

tests/all/custom_signal_handler.rs

 #[cfg(any(
    target_os = "linux",
-    all(target_os = "macos", feature = "posix-signals-on-macos")
+    all(
+        any(target_os = "macos", target_os = "ios"),
+        feature = "posix-signals-on-macos"
+    )
 ))]
 #[cfg(not(miri))]


As a heads up I've posted #7509 which will conflict with this, although what you're doing here of "where macos is needed also allow ios" would also apply to that PR.

alexcrichton · 2023-11-08T22:22:03Z

tests/all/debug/lldb.rs

@@ -12,7 +12,7 @@ fn lldb_with_script(args: &[&str], script: &str) -> Result<String> {
    let mut cmd = Command::new(&lldb_path);

    cmd.arg("--batch");
-    if cfg!(target_os = "macos") {
+    if cfg!(any(target_os = "macos", target_os = "ios")) {


I think it's ok to skip iOS in this file, it's unlikely these tests will ever complete successfully on iOS (and they're disabled by default too)

(ditto for all other tests/all/debug/*.rs files)

turbolent · 2024-09-07T22:47:30Z

@alexcrichton @jmp-0x7C0 I just wanted to report that making similar changes on main, i.e., extending cases of target_os = "macos" with target_os = "ios", let me run the GCD example in an iPhone 15 simulator and on a real iPhone 11 Pro.

Even if some details, like trap and signal handling, might still need to be fully tested, it would be great to allow building wasmtime for iOS upstream. I'm happy to open a PR on top of main

alexcrichton · 2024-09-08T18:20:55Z

@turbolent oh that's awesome, thanks for testing! If you'd like I think it would be reasonable to open an PR against main, likely starting from this PR to retain the original authorship and then adding bits and pieces on top as you've tested them.

This commit is somewhat of a rebase of bytecodealliance#7506 to port most of it to `main`. I've left out any test-related changes since we're not testing anything just yet. I've also found that rustc now has `target_vendor = "apple"` to cover both macOS and iOS targets (and presumably other targets like tvOS as well if they get added) Closes bytecodealliance#7506

jmp-0x7C0 added 3 commits November 7, 2023 11:47

Initial aarch64-apple-ios target support

f5f063e

Add cross compilation check

531bb25

Fix formatting

fbda3a9

alexcrichton reviewed Nov 8, 2023

View reviewed changes

github-actions bot added cranelift Issues related to the Cranelift code generator wasi Issues pertaining to WASI labels Nov 8, 2023

alexcrichton mentioned this pull request Jun 3, 2024

wasmtime-fiber do not build for target aarch64-apple-ios & aarch64-apple-ios-sim #8735

Open

alexcrichton mentioned this pull request Dec 20, 2024

Add aarch64-apple-ios to platform-check matrix #9888

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

iOS target support #7506

iOS target support #7506

jmp-0x7C0 commented Nov 8, 2023 •

edited

Loading

alexcrichton left a comment

alexcrichton Nov 8, 2023

alexcrichton Nov 8, 2023

turbolent Sep 6, 2024

alexcrichton Nov 8, 2023

turbolent Sep 7, 2024

alexcrichton Nov 8, 2023

alexcrichton Nov 8, 2023

alexcrichton Nov 8, 2023

alexcrichton Nov 8, 2023

turbolent commented Sep 7, 2024 •

edited

Loading

alexcrichton commented Sep 8, 2024

iOS target support #7506

Are you sure you want to change the base?

iOS target support #7506

Conversation

jmp-0x7C0 commented Nov 8, 2023 • edited Loading

alexcrichton left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turbolent commented Sep 7, 2024 • edited Loading

alexcrichton commented Sep 8, 2024

jmp-0x7C0 commented Nov 8, 2023 •

edited

Loading

turbolent commented Sep 7, 2024 •

edited

Loading