真机 ARM64 架构转模拟器 ARM64 架构

原创李超搜狐技术产品

本文字数：2051字

预计阅读时间：15分钟

需要转换架构的原因

老版 Mac 使用 Intel 芯片，是x86_64架构，相应地在老版 Mac 上运行的模拟器使用的也就是 x86_64架构。

由于模拟器的 x86_64 架构与真机的 arm64、armv7 等架构不冲突，业界为了方便库文件管理，通常会将模拟器架构与真机架构通过 lipo 命令合并为一个 fat 文件。

对于 Intel 芯片的 Mac 这样处理就很高效合理的，但是 Apple 推出了 M 系列芯片的新版 Mac，这就导致模拟器也变成了 arm64 架构，同时 lipo 命令合并二进制文件时不允许出现同名的两个不同架构。也就是只要还采用通用二进制文件（fat 文件）的库管理方式，就无法同时使用真机 arm64 架构和模拟器 arm64 架构。

对于上述的问题， Apple 提供了两个解决方案：

1、XCFramework。可以根据编译环境指定使用的库文件，不用合成就避免了架构重名的问题。但是项目使用的第三方库很多，其他部门的库内又链接了其他的第三方库，全部更换不现实。（我们项目目前只有一个部门支持了XCFramework）；

2、Rosetta Simulator。在 Xcode -》Product -》Destination 选项中，可以选择显示 Rosetta 模拟器，这样模拟器运行时使用的依旧是 x86_64 架构，同时搭配 Excluded Architectures = arm64 ，可以解决大部分项目模拟器运行的问题：

但是，visionOS Simulator 被 Apple 远程禁止了 Rosetta 选项！（早期的 Xcode15 beta 版还能显示 Rosetta 的 visionOS 模拟器，更新了一次就不见了。解包下载下来的 visionOS_1_beta_7_Simulator_Runtime，在 Contents/Resources/profile.plist 文件中可以看到支持的架构是包含x86_64的，应该是在Xcode层面禁止了Rosetta选项的出现）。如果我们想要提前验证项目在visionOS上跑起来的效果的话，就需要研究能否将链接库中的真机arm64架构提供给模拟器使用。

真机架构与模拟器架构的区别

为了弄清楚真机架构与模拟器架构的区别，我们需要将库文件解剖并对比二进制文件中的差异。

得益于外网的这篇博文arm64-to-sim，我们可以看到博主利用llvm对同一代码分别编译了真机与模拟器架构版本，并直接对比出了差异：

# in the FirebaseAnalytics.xcframework directory 
$ otool -fahl ios-arm64_i386_x86_64-simulator/FirebaseAnalytics.framework/FirebaseAnalytics | grep -E 'cmd |\.o' > simulator_cmds 
$ otool -fahl ios-arm64_armv7/FirebaseAnalytics.framework/FirebaseAnalytics | grep -E 'cmd |\.o' > native_cmds 
$ diff -u native_cmds simulator_cmds 
-ios-arm64_armv7/FirebaseAnalytics.framework/FirebaseAnalytics(FirebaseAnalytics_vers.o): 
+ios-arm64_i386_x86_64-simulator/FirebaseAnalytics.framework/FirebaseAnalytics(FirebaseAnalytics_vers.o):
cmd LC_SEGMENT_64 
-      cmd LC_VERSION_MIN_IPHONEOS 
+      cmd LC_BUILD_VERSION      
cmd LC_SYMTAB 
(...)

从上面的结果可以看到，区别只有一处，真机架构使用的loadcommand是LC_VERSION_MIN_IPHONEOS，而模拟器是LC_BUILD_VERSION。我们使用otool命令：

otool -lV xxx.o

可以查看二进制文件中load command的内容，对比结果如下图：

如何修改

知道了区别在于load command，自然是要将LC_VERSION_MIN_IPHONEOS改为LC_BUILD_VERSION。但是Mach-O是一种很紧凑的文件格式，Mach-O中的三个区域Header & Load Commands & Data，其中Header记录了平台、文件类型、指令数、指令总大小等信息，Load Commands紧跟Header，其中部分Load Command包含了Data中数据段的起始位置和数据大小：

修改LC_VERSION_MIN_IPHONEOS为LC_BUILD_VERSION会导致Mach-O整体大小发生变化（如图所示，cmdsize不同），Header中的大小信息需要同步修改，由于Data处于Load Commands位置后面，Data所在位置也就发生了偏移，部分load command所指向的位置也需要进行对应的偏移。

体现到代码上，参照arm64-to-sim开源命令行工具。

1、提取静态库中的arm64架构：

private static func extract(inputFileAtUrl url: URL, withArch arch: String, toURL: URL) throws {
        try shellOut(to: "lipo", arguments: [
            "-thin",
            arch,
            url.path,
            "-output",
            "lib.\(arch)"
        ], at: toURL.path)
}

2、将提取出的文件切为最小组成成分，并依次处理：

try shellOut(to: "ar", arguments: ["x", extractionUrl.appendingPathComponent("lib.arm64").path])
if let emulator = FileManager.default.enumerator(atPath: extractionUrl.path) {
  for file in emulator {
    if let fileString = file as? String {
      if fileString.hasSuffix(".o") {
        Transmogrifier.processBinary(atPath: extractionUrl.appendingPathComponent(fileString).path, minos: minos, sdk: sdk)
      }
    }
  }
}

3、更新Header中数据大小：

var header: mach_header_64 = headerData.asStruct()
header.sizeofcmds = UInt32(editedCommandsData.count)

4、替换LC_VERSION_MIN_IPHONEOS，根据cmdsize变化更新其他load command：

static func updatePreiOS12ObjectFile(lc: Data, minos: UInt32, sdk: UInt32) -> Data {
        let offset = UInt32(abs(MemoryLayout<build_version_command>.stride - MemoryLayout<version_min_command>.stride))
        let cmd = Int32(bitPattern: lc.loadCommand)
        switch  cmd {
        case LC_SEGMENT_64:
            return updateSegment64(lc, offset)
        case LC_VERSION_MIN_IPHONEOS:
            return createVersionMin(lc, offset, minos: minos, sdk: sdk)
        case LC_DATA_IN_CODE, LC_LINKER_OPTIMIZATION_HINT:
            return updateDataInCode(lc, offset)
        case LC_SYMTAB:
            return updateSymTab(lc, offset)
        case LC_BUILD_VERSION:
            return updateVersionMin(lc, offset, minos: minos, sdk: sdk)
        default:
            return lc
        }
}

5、将处理后的切片合并组装：

try shellOut(to: "ar", arguments: ["cr", "lib.arm64", "*.o"])

踩坑&进阶

arm64-to-sim在计算LC_BUILD_VERSION大小时没有考虑build_tool_version：

Load command 11
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform IOSSIMULATOR
    minos 15.5
      sdk 15.5
   ntools 1
     tool LD
  version 764.0

Load command 34
      cmd LC_BUILD_VERSION
  cmdsize 24
 platform IOSSIMULATOR
    minos 13.0
      sdk 13.0
   ntools 0

参照MachOView源码：

struct build_tool_version {
  uint32_t tool;
  uint32_t version;
};

struct build_version_command {
  uint32_t cmd;       // LC_BUILD_VERSION
  uint32_t cmdsize;   // sizeof(build_version_command) + (ntools * sizeof(build_tool_version)
  uint32_t platform;  // MachoPlatform
  uint32_t minos;     // X.Y.Z is encoded in nibbles xxxx.yy.zz
  uint32_t sdk;       // X.Y.Z is encoded in nibbles xxxx.yy.zz
  uint32_t ntools;    // number build_tool_version entries
};

build_version_command的cmdsize 需要加上build_tool_version 的大小，不然会读取失败。

有些库中包含bitcode文件，bitcode文件与Mach-O文件结构并不相同，上述的处理过程并不能完成架构转换。

llvm提供了llvm-dis、llvm-as工具，llvm-dis可以将bitcode文件转换为文本格式的 .ll文件，llvm-as工具可以将 .ll文件转换为bitcode文件。

打开一个转换好的 .ll 文件，我们可以看到target triple对应的就是架构信息：

参照Xcode Build Log：

-Xlinker -reproducible -target arm64-apple-ios9.0-simulator -isysroot

此处target triple改为arm64-apple-ios8.0.0-simulator即可。

由于bitcode是llvm编译过程的中间产物，不同版本的llvm所生成的bitcode格式并不兼容，需要采用和Xcodecommand line tool所使用的llvm相近的版本。

结尾

如果你顺利地完成了以上所有步骤，将项目中的链接库全部转换完成，那么你就可以直接在arm64架构的模拟器上运行你们的项目了。

参考文档：

1、https://bogo.wtf/arm64-to-sim.html

2、https://github.com/luosheng/arm64-to-sim

继续滑动看下一个