Compilation fails on aarch64-apple-darwin

[est31]

I noticed it in the CI output of rust-lang/rustup#2517 :

  running "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-arch" "arm64" "-I" "include" "-Wall" "-Wextra" "-pedantic" "-pedantic-errors" "-Wall" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-fstack-protector" "-gfull" "-DNDEBUG" "-c" "-o/Users/runner/work/rustup/rustup/target/aarch64-apple-darwin/release/build/ring-fcf530fe8716448c/out/aesv8-armx-linux64.o" "/Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S"
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:18:17: error: unexpected token in '.section' directive
  .section .rodata
                  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:28:1: error: unknown directive
  .hidden GFp_aes_hw_set_encrypt_key
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:29:1: error: unknown directive
  .type GFp_aes_hw_set_encrypt_key,%function
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:161:1: error: unknown directive
  .size GFp_aes_hw_set_encrypt_key,.-GFp_aes_hw_set_encrypt_key
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:163:1: error: unknown directive
  .hidden GFp_aes_hw_encrypt
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:164:1: error: unknown directive
  .type GFp_aes_hw_encrypt,%function
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:191:1: error: unknown directive
  .size GFp_aes_hw_encrypt,.-GFp_aes_hw_encrypt
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:193:1: error: unknown directive
  .hidden GFp_aes_hw_decrypt
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:194:1: error: unknown directive
  .type GFp_aes_hw_decrypt,%function
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:221:1: error: unknown directive
  .size GFp_aes_hw_decrypt,.-GFp_aes_hw_decrypt
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:223:1: error: unknown directive
  .hidden GFp_aes_hw_ctr32_encrypt_blocks
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:224:1: error: unknown directive
  .type GFp_aes_hw_ctr32_encrypt_blocks,%function
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:403:1: error: unknown directive
  .size GFp_aes_hw_ctr32_encrypt_blocks,.-GFp_aes_hw_ctr32_encrypt_blocks
  ^
  /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/pregenerated/aesv8-armx-linux64.S:407:19: error: unexpected token in '.section' directive
  .section .note.GNU-stack,"",%progbits
                    ^
  thread 'main' panicked at 'execution failed', /Users/runner/.cargo/registry/src/git.colasdn.top-1ecc6299db9ec823/ring-0.16.15/build.rs:664:9

cc @shepmaster

[est31]

Pr with a fix: #1055

[briansmith]

I'm working on merging recent BoringSSL changes that are relevant to this and then I'll deal with #1055.

[briansmith]

I see rust-lang/rust#73628 says that even rustc doesn't have support and the final target triple/triples isn't/aren't decide yet. I think it would be great if we could go over to rust-lang/rust#73628 and nail down at least what the final target triple names will be. (I think the default answer should be "whatever clang uses".)

In that issue, I saw an interesting comment:

arm64e is currently required when building kernel modules for macOS on Apple Silicon machines, but arm64e binaries will not run in userspace (currently arm64, or running x86_64 under Rosetta emulation is required).

I have a WIP to add arm64e support to ring based on merging BoringSSL's arm64e support. If arm64e support is mandatory for kernel space and forbidden from userspace then we'll almost definitely need to support both.

[briansmith]

@chadseld Any thoughts on ^?

[briansmith]

The PR in #1055 is based on the assumption that any assembly code compiled for Aarch64 iOS devices will work unmodified (modulo BTI and pointer authentication) on ARM64 macOS. Are there any (other) ABI differences at all?

[briansmith]

Well, I see the current rustc nightly uses the name aarch64-apple-darwin

[briansmith]

My understanding is that there is no emulator so one can only run a binary produced for this target on the actual hardware. Is that correct?

What is the status of cross-compiling to this target? Would it be a waste of time to try to get the CI/CD going to verify that things still build?

[est31]

I think it would be great if we could go over to rust-lang/rust#73628 and nail down at least what the final target triple names will be.

A better thread for the apple silicon target would be rust-lang/rust#73908 . Regarding the particular concern of ARM 8.3 version numbers, there is precedent with x86_64 where core2 is assumed for apple based targets, allowing for max_atomic_width to be set to 128 bits instead of 64. linux based targets on the other hand can only assume 64 bits. The names of the targets (x86_64-apple-darwin vs x86_64-unknown-linux-gnu) don't reflect this difference in minimum hardware version, it's solely implied by the fact that apple doesn't support pre-core2 CPUs.

[est31]

What is the status of cross-compiling to this target? Would it be a waste of time to try to get the CI/CD going to verify that things still build?

Officially, Xcode 12 supports cross compilation to apple silicon. Things seem to be a bit in flux still though. Rust CI uses a beta of Xcode 12.2 for example. Best ask @shepmaster for the details.

[chadseld]

I've been using aarch64-apple-darwin for building rust from source. That is now officially the rust tier 2 platform. Yes, you should be able to cross compile, the same as when building for iOS. But I have not attempted this. I know of no emulator appropriate for CI testing. As for this compilation failure, https://github.com/briansmith/ring/pull/1055/files fixes it. I'd prefer a better ASM_TARGETS triple. It feels dirty to use ios64 there since mac on arm is going to be a major platform going forward, but that's entirely internal to ring build scripts.

[briansmith]

I'd prefer a better ASM_TARGETS triple. It feels dirty to use ios64 there since mac on arm is going to be a major platform going forward, but that's entirely internal to ring build scripts.

I'm working on that. We need to get agreement with BoringSSL (and I hope OpenSSL upstream) to make it easy to maintain. The paperwork necessary for 1Password to contribute to BoringSSL is in progress.

[briansmith]

BoringSSL upstream has fixed the conditional compilation logic that was blocking the BoringSSL merge: https://boringssl.googlesource.com/boringssl/+/c46b1736a14135cc5b337aad3f359c819963ac68. Will finish the BoringSSL merge and then test and merge #1055.

[briansmith]

openssl/openssl#12254 is the upstream OpenSSL issue. I see in the PR they merged, https://github.com/openssl/openssl/pull/12591/files, that they are using ios64 as the perlasm flavour name. Unless/until BoringSSL upstream changes that, I'll continue using ios64 as the perlasm flavour name too.