1. 24 Sep, 2020 1 commit
    • Mark Mentovai's avatar
      mac-arm64: Provide an arm64-native ninja-mac for builds in ¼ of the time · 4005bb74
      Mark Mentovai authored
      ninja-mac is expanded to become a universal (“fat”) executable. The
      existing x86_64 slice was taken from the x86_64 ninja-mac as it
      previously existed in this location, and a new arm64 slice was added.
      
      This is an aid to native development on arm64. In macOS, subprocesses
      inherit their parent’s “binpref,” meaning that children of a translated
      process will, by default, also be translated, if there’s a choice
      between native and translated. Where ninja-mac is x86_64-only and runs
      translated on arm64, all tools it invokes will also run translated, even
      if native versions are available. This has an impact on any part of the
      toolchain for which universal versions are available: in Chrome’s case,
      tools such as ld64 are affected. In Crashpad’s build, which uses the
      compiler provided by Xcode, it even affects the compiler, leading to
      significant differences in build time on arm64.
      
      mark@arm-and-hammer zsh% file $(which ninja-mac)
      …/ninja-mac: Mach-O 64-bit executable x86_64
      mark@arm-and-hammer zsh% time ninja -C out/release
      ninja: Entering directory `out/release'
      [1/1] Regenerating ninja files
      [511/511] LINK ./crashpad_minidump_test
      ninja -C out/release  1384.03s user 111.05s system 393% cpu 6:19.53 total
      
      mark@arm-and-hammer zsh% file $(which ninja-mac)
      …/ninja-mac: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
      …/ninja-mac (for architecture x86_64):	Mach-O 64-bit executable x86_64
      …/ninja-mac (for architecture arm64):	Mach-O 64-bit executable arm64
      mark@arm-and-hammer zsh% time ninja -C out/release
      ninja: Entering directory `out/release'
      [1/1] Regenerating ninja files
      [511/511] LINK ./crashpad_minidump_test
      ninja -C out/release  606.80s user 34.71s system 701% cpu 1:31.41 total
      
      This differs from the previous attempt, e64cd3ae
      (https://chromium-review.googlesource.com/c/2288417) in that the arm64
      version was built with Xcode 12.2b1 (12B5018i). The linker in this
      version of Xcode produces linker-signed output for arm64 by default. As
      of macOS 11.0db6 (20A5364e), all arm64 code must be signed. More
      information at
      https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-universal-apps-beta-release-notes#Code-Signing.
      In the previous attempt, an older Xcode was used and the output was not
      signed at all. Because it did not run on systems upgraded to 11.0db6,
      this version of ninja-mac was backed out in a070dd18
      (https://chromium-review.googlesource.com/c/2393775).
      
      To create this ninja-mac:
      
      % git clone https://github.com/ninja-build/ninja.git
      % cd ninja
      % git checkout v1.8.2
      % mkdir ../build
      % cd ../build
      % LDFLAGS=-Wl,-s ../ninja/configure.py --bootstrap
      % lipo -create -output ninja-mac $(which ninja-mac) ninja
      
      An explanation of the LDFLAGS: e64cd3ae used “strip” on the output,
      matching the stripped x86_64 slice, but “strip” is not currently
      compatible with linker-signed executables. This is documented at
      https://developer.apple.com/documentation/xcode-release-notes/xcode-12_2-beta-release-notes#Apple-Clang-Compiler.
      I was unable to use the recommended workaround in this case. Rather than
      leave the output unstripped, I asked ld64 to strip symbols using its -s
      option, which it believes is obsolete, but in fact provides the intended
      behavior.
      
      The x86_64 slice is unsigned, as it was previously. The new arm64 slice
      is linker-signed with an ad-hoc signature. The x86_64 slice was built
      with the macOS 10.12 SDK and runs on Mac OS X 10.6 or later. The arm64
      slice was built with and has a minimum runtime requirement of macOS
      11.0. In practice, the difference doesn’t matter, as the 11.0 SDK is
      required to build for arm64, and no macOS version earlier than 11.0 will
      run on arm64.
      
      Bug: chromium:1103315
      Change-Id: I9f201d0d6f476e187acc0008681c3fd2c1a72aa0
      Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2427051Reviewed-by: 's avatarNico Weber <thakis@chromium.org>
      Commit-Queue: Mark Mentovai <mark@chromium.org>
      4005bb74
  2. 22 Sep, 2020 3 commits
  3. 21 Sep, 2020 2 commits
  4. 18 Sep, 2020 3 commits
  5. 17 Sep, 2020 3 commits
  6. 16 Sep, 2020 6 commits
  7. 15 Sep, 2020 4 commits
  8. 14 Sep, 2020 1 commit
  9. 11 Sep, 2020 6 commits
  10. 09 Sep, 2020 1 commit
  11. 08 Sep, 2020 1 commit
  12. 07 Sep, 2020 1 commit
  13. 04 Sep, 2020 1 commit
    • Nico Weber's avatar
      Revert "mac: Add an arm64 slice to ninja-mac." · a070dd18
      Nico Weber authored
      This reverts commit e64cd3ae.
      
      Reason for revert: A never macOS 11 beta made it so that
      native arm binaries need to be signed, and the Xcode beta used
      to build this arm64 slice here didn't do ad-hoc signing by default
      yet, see https://crbug.com/1125021
      
      Original change's description:
      > mac: Add an arm64 slice to ninja-mac.
      > 
      > To build the arm ninja binary, I downloaded a zip with the ninja 1.8.2
      > code, and ran `./configure --bootstrap` on an arm mac, with Xcode 12 beta
      > installed, followed by `strip ninja`. That gave me a working ninja 1.8.2
      > arm binary. I then copied it to my intel mac and ran
      > 
      >     lipo -create -output ninja-mac ninja-mac ~/Downloads/ninja
      > 
      > to make a fat binary.
      > 
      > No intended behavior change on non-arm macs.
      > 
      > (This means the x86_64 slice, which is the previously existing binary,
      > has a LC_VERSION_MIN_MACOSX version 10.6, while the arm64 slice has
      > LC_BUILD_VERSION minos 11.0, according to `otool -arch ax86_64 -l ninja-mac`
      > and `otool -arch arm64 -l ninja-mac`.)
      > 
      > Bug: 1103315,762354
      > Change-Id: I2c4bea53a01d7a6135f9cd5554e3123dba960664
      > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2288417
      > Auto-Submit: Nico Weber <thakis@chromium.org>
      > Reviewed-by: Mark Mentovai <mark@chromium.org>
      > Commit-Queue: Mark Mentovai <mark@chromium.org>
      > Commit-Queue: Nico Weber <thakis@chromium.org>
      
      TBR=thakis@chromium.org,dpranke@google.com,mark@chromium.org,infra-scoped@luci-project-accounts.iam.gserviceaccount.com
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: 1103315
      Bug: 762354
      Change-Id: Icd968a2fecb9509722c43d9cb03db92e6e3829e4
      Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/depot_tools/+/2393775Reviewed-by: 's avatarNico Weber <thakis@chromium.org>
      Commit-Queue: Nico Weber <thakis@chromium.org>
      a070dd18
  14. 03 Sep, 2020 2 commits
  15. 02 Sep, 2020 4 commits
  16. 31 Aug, 2020 1 commit