Swift库二进制接口(ABI)兼容性研究

转载

mob604756ea26ec 2018-06-15 15:17:00

前言

阿里云APP组件化过程中，我们拆分出了若干基础组件库和业务代码库，由于代码是采用Swift编写的，所以这些库都是动态库形式。在上一个正式版本，组件化达到了完全形态，主工程只剩下一个壳，所有代码都以pod组件的形式引入，最后交付的是一个主工程的壳二进制程序，和十几个动态库Framework。这些动态库都是运行时才链接到主程序中的。

开发中，我们在某个组件上工作时，其他组件也都是以动态库二进制形式引入的，节省Rebuild源码成本。但开发过程中我们遇到了一些问题。

遇到问题

组件拆分出来以后，无可避免，组件之间会存在一些非扁平的依赖关系，如A依赖B依赖C，同时A依赖C。开发A过程中，可能有需要改动C的情况，于是我们将C更新、打包、发布，而B保持不变(只有A用到C加的特性)，A依赖C的新版本继续开发。但我们发现，有一些改动会导致APP闪退，只有在B重新依赖C的新版本也编译、打包、发布新版本之后，才恢复正常。我们注意到，出现这种情况时，一般是我们改动了A中某些类的属性。显而易见，我们遇到的是二进制兼容性问题。

理论上ObjC使用静态库也会遇到这种问题的，但是ObjC2.0引入了non-fragile特性，同时runtime中采用消息转发实现方法调用，规避了大部分会引起ABI不兼容的情况。所以在ObjC中，只要接口兼容，底层组件改动一般是不需要自下往上重新编译链接的。

而Swift，在我们认识里，它没有ObjC那么“动态”，又不像C/C++那么直接(寻址是基地址+偏移量，内存布局改变引起ABI不兼容)，那它会存在哪些能引起ABI不兼容的情况呢？上个版本我们没有弄明白，保险起见，底层改动后我们都把上层重新编译连接，非常蛋疼。所以，这两天我尝试把这个问题弄清楚。

复现实例

我们准备三个代码文件：

// Foo.swift

public class SimpleClass {

    public var x: Int = 0
    public var y: Int = 0

    public init() {
        x = 1
        y = 2
    }

    public func sum() -> Int {
        return x + y
    }
}

// Bar.swift

import Foo

public func bar() -> Int {
    return SimpleClass().sum()
}

// main.swift

import Foundation
import Foo
import Bar

print("bar \(bar())")

然后分别编译出动态库，链接到main，运行：

$ swiftc -emit-module -emit-library Foo.swift
$ swiftc -emit-module -emit-library Bar.swift -I. -L. -lFoo
$ swiftc -I. -L. -lFoo -lBar main.swift
$ ./main
bar 3 // output

然后我们给Foo.swift增加一个字段diff:

// Foo.swift

public class SimpleClass {

    public var diff: Int?
    public var x: Int = 0
    public var y: Int = 0

    public init() {
        x = 1
        y = 2
    }

    public func sum() -> Int {
        return x + y
    }
}

单独编译Foo.swift，Bar.swift和main.swift不再重新编译:

$ swiftc -emit-module -emit-library Foo.swift
$ ./main
[1]    52482 segmentation fault  ./main  // output
$ swiftc -I. -L. -lFoo -lBar main.swift
[1]    52645 segmentation fault  ./main  // output

可以看到，无论是否重新编译main，只要不重新编译Bar，运行main就会闪退。

排查

我们没有挑选一些在C/C++里容易理解的ABI不兼容的场景，如直接引用发生变化的对象成员变量，继承关系下父类字段增删等。上述复现实例中，我们在SimpleClass这个类中增加了字段，改变了对象的内存布局，但是，按照C/C++的思路，我们并未在Bar中直接引用任何成员变量，为什么会出现错误呢？我们也已经知道，Swift方法调用依赖vtable，但我们也并未对实例方法做增删。

还是要从内存布局说起。

对象内存布局

Swift对象的内存布局我也是这两天慢慢明白过来的，现在放在最前头，后边说起来就容易理解了。在上一次我为了实现HandyJSON做这方面调研的时候，这一块资料很少，但现在情况不同了。特别推荐Mike Ash的一个分享视频，他的思路很棒，主要依赖mach_vm_read_overwrite和dladder两个系统函数。前者利用系统调用检查一个指针是否合法，后者检查一个内存地址上是否绑定了什么symbol。基于此，从一个对象的起始指针出发，广度遍历一下可见的内存，构造指针继续往下，最后将得到和这个对象相关的所有地址、所有符号，把这些信息生成一张图，最后大概是这个样子(这个是简单情况)：

Paste_Image.png

从这个视频，我们知道，普通Swift对象，即使是纯Swift对象，其实instance的布局也是和ObjC保持一致，大概是这样：

Paste_Image.png

我们打开Swift ABI文档。在Class Metadata这一章节，我们看到，在ObjC中，isa指向一个Class类对象，Swift类似，但指向的是一个与Class类兼容的metadata，这个metadata用Class *去解释是没有问题的，同时它尾部追加了Swift中使用的一些字段。比如vtable。vtable相关的资料，可以参考:Swift Method Dispatching。

我们直接将Foo.swift编译为汇编代码(swiftc -S Foo.swift)：

525 __TWoFC3Foo11SimpleClass3sumfT_Si:
526     .quad   152
527
528     .globl  __TMLC3Foo11SimpleClass
529 .zerofill __DATA,__common,__TMLC3Foo11SimpleClass,8,3
530     .section    __DATA,__data
531     .align  3
532 __TMfC3Foo11SimpleClass:
533     .quad   __TFC3Foo11SimpleClassD
534     .quad   __TWVBo
535     .quad   __TMmC3Foo11SimpleClass  // isa指向的位置
536     .quad   _OBJC_CLASS_$_SwiftObject
537     .quad   __objc_empty_cache
538     .quad   0
539     .quad   l__DATA__TtC3Foo11SimpleClass+1
540     .long   3
541     .long   0
542     .long   32
543     .short  7
544     .short  0
545     .long   176
546     .long   16
547     .quad   __TMnC3Foo11SimpleClass-(__TMfC3Foo11SimpleClass+80)
548     .quad   0
549     .quad   __TFC3Foo11SimpleClassg1xSi  // vTable起点
550     .quad   __TFC3Foo11SimpleClasss1xSi
551     .quad   __TFC3Foo11SimpleClassm1xSi
552     .quad   __TFC3Foo11SimpleClassg1ySi
553     .quad   __TFC3Foo11SimpleClasss1ySi
554     .quad   __TFC3Foo11SimpleClassm1ySi
555     .quad   __TFC3Foo11SimpleClasscfT_S0_
556     .quad   __TFC3Foo11SimpleClass3sumfT_Si  // sum方法
557     .quad   16
558     .quad   24
559
560     .section    __TEXT,__swift3_typeref,regular,no_dead_strip
561     .align  4
562 L___unnamed_7:
563     .asciz  "C3Foo11SimpleClass"

然后demangle相关的几个符号：

$ xcrun swift-demangle *

output:

_TMmC3Foo11SimpleClass ---> metaclass for Foo.SimpleClass
_TMfC3Foo11SimpleClass ---> full type metadata for Foo.SimpleClass
_TFC3Foo11SimpleClassD ---> Foo.SimpleClass.__deallocating_deinit
_TMmC3Foo11SimpleClass ---> metaclass for Foo.SimpleClass
_TMnC3Foo11SimpleClass ---> nominal type descriptor for Foo.SimpleClass
_TMfC3Foo11SimpleClass ---> full type metadata for Foo.SimpleClass
_TFC3Foo11SimpleClassg1xSi ---> Foo.SimpleClass.x.getter : Swift.Int
_TFC3Foo11SimpleClasss1xSi ---> Foo.SimpleClass.x.setter : Swift.Int
_TFC3Foo11SimpleClassm1xSi ---> Foo.SimpleClass.x.materializeForSet : Swift.Int
_TFC3Foo11SimpleClass3sumfT_Si ---> Foo.SimpleClass.sum () -> Swift.Int

很棒，一切符合预期。

调用细节

然后我们看一下Bar.swift中发生了什么(swiftc -I. -L. -lFoo -S Bar.swift):

 38 __TF3Bar3barFT_Si:
 39     .cfi_startproc
 40     pushq   %rbp
 41 Ltmp3:
 42     .cfi_def_cfa_offset 16
 43 Ltmp4:
 44     .cfi_offset %rbp, -16
 45     movq    %rsp, %rbp
 46 Ltmp5:
 47     .cfi_def_cfa_register %rbp
 48     subq    $32, %rsp
 49     callq   __TMaC3Foo11SimpleClass
 50     movq    %rax, %rdi
 51     callq   __TFC3Foo11SimpleClassCfT_S0_  // 构造SimpleClass实例
 52     movq    (%rax), %rdi
 53     movq    %rdi, -8(%rbp)
 54     movq    %rax, %rdi
 55     movq    -8(%rbp), %rcx
 56     movq    %rax, -16(%rbp)
 57     callq   *136(%rcx)  // 调用sum方法
 58     movq    -16(%rbp), %rdi
 59     movq    %rax, -24(%rbp)
 60     callq   _rt_swift_release
 61     movq    -24(%rbp), %rax
 62     addq    $32, %rsp
 63     popq    %rbp
 64     retq
 65     .cfi_endproc

跳过细节，我们直接看line 57： callq *136(%rcx)行，这正是对sum方法的调用。rcx寄存器存储的值为SimpleClass.metadata的起始指针，偏移136字节后，便是上述中_TFC3Foo11SimpleClass3sumfT_Si ---> Foo.SimpleClass.sum () -> Swift.Int符号。

引起不兼容的原因

这时候我们就可以考虑一下，在复现实例中，我们加入diff字段发生的事情了。加入diff字段后重新编译Foo.swift，可以看到汇编代码中metadata布局变成了：

671     .quad   __TMnC3Foo11SimpleClass-(__TMfC3Foo11SimpleClass+80)
672     .quad   0
673     .quad   __TFC3Foo11SimpleClassg4diffGSqSi_
674     .quad   __TFC3Foo11SimpleClasss4diffGSqSi_
675     .quad   __TFC3Foo11SimpleClassm4diffGSqSi_
676     .quad   __TFC3Foo11SimpleClassg1xSi
677     .quad   __TFC3Foo11SimpleClasss1xSi
678     .quad   __TFC3Foo11SimpleClassm1xSi
679     .quad   __TFC3Foo11SimpleClassg1ySi
680     .quad   __TFC3Foo11SimpleClasss1ySi
681     .quad   __TFC3Foo11SimpleClassm1ySi
682     .quad   __TFC3Foo11SimpleClasscfT_S0_
683     .quad   __TFC3Foo11SimpleClass3sumfT_Si

也就是说，Swift为新增的字段添加了三个方法，插在vtable其他方法的前面。这时候，__TFC3Foo11SimpleClass3sumfT_Si的位置就变了，而Bar中仍然以callq *136(%rcx)调用sum函数，自然就发生了错误，导致闪退。

其他情况

上述例子主要是展示了一种研究ABI兼容性的思路。据此，我们可以研究其他情况。

Struct

Swift中，Struct不允许继承，所以它的方法派发不必要依赖vtable实现，而是直接被编译为全局函数(未研究可见修饰符的影响)。那它还会遇到Class中遇到的问题吗？测试结果是，仍然会。我们把SimpleClass修改为SimpleStruct，同时直接在x和y字段之间增加diff字段方便印证逻辑，看下Bar中的变化：

// Foo.swift节选
public struct SimpleStruct {
    public var x: Int = 0
    public var diff: Int = 0
    public var y: Int = 0
...
}

// foo.s节选
 63 __TFV3Foo12SimpleStruct3sumfT_Si:
 64     .cfi_startproc
 65     pushq   %rbp
 66 Ltmp6:
 67     .cfi_def_cfa_offset 16
 68 Ltmp7:
 69     .cfi_offset %rbp, -16
 70     movq    %rsp, %rbp
 71 Ltmp8:
 72     .cfi_def_cfa_register %rbp
 73     addq    %rdx, %rdi  // .x + .y
 74     seto    %al
 75     movq    %rsi, -8(%rbp)
 76     movq    %rdi, -16(%rbp)
 77     movb    %al, -17(%rbp)
 78     jo  LBB2_2
 79     movq    -16(%rbp), %rax
 80     popq    %rbp
 81     retq
 82 LBB2_2:
 83     ud2
 84     .cfi_endproc

// bar.s节选
 46 Ltmp5:
 47     .cfi_def_cfa_register %rbp
 48     callq   __TFV3Foo12SimpleStructCfT_S0_
 49     movq    %rax, %rdi  // .x
 50     movq    %rdx, %rsi
 51     movq    %rcx, %rdx  // .y
 52     callq   __TFV3Foo12SimpleStruct3sumfT_Si
 53     popq    %rbp
 54     retq
 55     .cfi_endproc

可以看到，在bar.s中，调用sum时直接调用全局符号来完成的，而非Class中以偏移量实现。而且，在调用前，参数并不是以指向struct实例的指针方式提供self.，而是直接传值！传值过程依赖于SimpleStruct的内存布局，所以，一旦布局改变，这里就会发生错误。

Protocol

参考Swift进阶之内存模型和方法调度一文，Swift对于协议类型的采用如下的内存模型 - Existential Container：

Paste_Image.png

Existential Container包括以下三个部分：
前三个word：Value buffer。用来存储Inline的值，如果word数大于3，则采用指针的方式，在堆上分配对应需要大小的内存
第四个word：Value Witness Table(VWT)。每个类型都对应这样一个表，用来存储值的创建，释放，拷贝等操作函数。
第五个word：Protocol Witness Table(PWT)，用来存储协议的函数。

Paste_Image.png

那么，显然，如果属性增删导致属性存储区在栈、堆之间变化，或者类的方法(包括可见属性的getter、setter)增删引起vtable变化，都会引起不兼容问题。

Extension

我们常常在各个地方为类增加扩展，显然它是不会引起不兼容问题的。为Foo.swift增加一个扩展，其中实现一个空方法f0()，我们从汇编代码可以看到只是增加了一个global方法定义:

320     .globl  __TFC3Foo11SimpleClass2f0fT_T_
321     .align  4, 0x90
322 __TFC3Foo11SimpleClass2f0fT_T_:
323     .cfi_startproc
324     pushq   %rbp
325 Ltmp39:
326     .cfi_def_cfa_offset 16
327 Ltmp40:
328     .cfi_offset %rbp, -16
329     movq    %rsp, %rbp
330 Ltmp41:
331     .cfi_def_cfa_register %rbp
332     movq    %rdi, -8(%rbp)
333     popq    %rbp
334     retq
335     .cfi_endproc

静态方法

静态方法和扩展类似，只是增加了global方法定义，不会影响到类的metadata，所以不会引起不兼容问题。

总结

Swift 3出来时，我们曾看到Chris Lattner的邮件: 回顾Swift3，展望Swift4。他提到Swift4阶段1的任务时说：

Resilience: This provides a way for public APIs to evolve over time, even in the face of ABI stability. For example, we don’t want the C++ “fragile base class" problem to ever exist in Swift. ** Much of the design and implementation work was done in the Swift 3 timeframe**, but there are still major missing pieces, including the user-visible part of the model (e.g. new attributes).

现在看起来，Swift的整个设计完全是静态的，"易碎的"(fragile)，这使得Much of the design and implementation work was done in the Swift 3 timeframe这句话让我十分费解。我不知道是不是我理解的方向都错了。

但回到我们工程，这个问题已经拦在前面了，我们只能尽量不要频繁在底层组件做非二进制兼容的改动，即使有必要，我们也应该找到一个方案，自动化地完成有时序依赖的构建过程。

更多的情况，我将继续研究，大家有不同的见解，欢迎交流~

Reference

作者：xycn

链接：https://www.jianshu.com/p/5860f5542f21

來源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

------------------越是喧嚣的世界，越需要宁静的思考------------------ 合抱之木，生于毫末；九层之台，起于垒土；千里之行，始于足下。积土成山，风雨兴焉；积水成渊，蛟龙生焉；积善成德，而神明自得，圣心备焉。故不积跬步，无以至千里；不积小流，无以成江海。骐骥一跃，不能十步；驽马十驾，功在不舍。锲而舍之，朽木不折；锲而不舍，金石可镂。蚓无爪牙之利，筋骨之强，上食埃土，下饮黄泉，用心一也。蟹六跪而二螯，非蛇鳝之穴无可寄托者，用心躁也。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。