了解OC
语言Runtime
机制的开发者都知道,几乎所有的方法调用都会转化成objc_msgSend(void /* id self, SEL op, ... */ )
的调用,今天探索一下ARM64架构下的objc_msgSend
的汇编实现,objc_msgSend
用汇编语言进行实现,具体理由有两个:首先纯 C 语言无法实现这么一个函数:接收不定个数且未知类型的参数作为入参跳转至任意函数指针(即调用实现);其次,执行速度对 objc_msgSend
来说非常重要,汇编语言能最大化提升该项指标。具体可以看这个,为什么objc_msgSend必须用汇编
在真机环境下,设置一个符号断点即可查看
objc_msgSend
的汇编实现image
图片来源
objc_msgSend
主要有以下几个步骤:
- 通过
isa
获取传入的对象的类 - 获取这个类的方法缓存表
- 通过传入的
selector
,在缓存中查找方法 - 如果缓存中没有,调用C函数
- 跳到这个方法的
IMP
下面对汇编程序逐行分析
0x232c6f520 <+0>: cmp x0, #0x0 ; =0x0
0x232c6f524 <+4>: b.le 0x232c6f58c ; <+108>
判断x0
是nil
还是tagged pointer
,等于0
为nil
,小于0
为tagged pointer
0x232c6f528 <+8>: ldr x13, [x0]
将x0
中所表示的self
的isa
地址放到x13
寄存器中
0x232c6f52c <+12>: and x16, x13, #0xffffffff8
当前对象逻辑与mask
获取类的地址,x16 = isa & mask
,
# if __arm64__
# define ISA_MASK 0x0000000ffffffff8ULL
# define ISA_MAGIC_MASK 0x000003f000000001ULL
# define ISA_MAGIC_VALUE 0x000001a000000001ULL
# define ISA_BITFIELD \
uintptr_t nonpointer : 1; \
uintptr_t has_assoc : 1; \
uintptr_t has_cxx_dtor : 1; \
uintptr_t shiftcls : 33; /*MACH_VM_MAX_ADDRESS 0x1000000000*/ \
uintptr_t magic : 6; \
uintptr_t weakly_referenced : 1; \
uintptr_t deallocating : 1; \
uintptr_t has_sidetable_rc : 1; \
uintptr_t extra_rc : 19
arm64架构下使用 non-pointer isa
技术,和之前的isa
相比,isa
字段不仅存放了Class的信息,还存放了其他信息(上面的代码块),这里通过AND
运算除去低位的冗余信息将最终的Class的地址放入x16
寄存器中
0x232c6f530 <+16>: ldp x10, x11, [x16, #0x10]
该指令会将Class中的方法缓存哈希表bucket加载到x10
和 x11
两个寄存器中。ldp
指令会将有效的内存信息加载到该指令的前两个寄存器中,而第三个参数则对应该信息的内存地址,在该例中缓存哈希表地址为x16
寄存器中地址偏移16
后所处的位置,
struct objc_class : objc_object {
// Class ISA; // 8
Class superclass; // 8
cache_t cache; // fpointer and vtable
class_data_bits_t bits; //
};
ISA
和 superclass
各占8
个字节,所以偏移16
个字节后,指向cache_t cache
struct cache_t {
struct bucket_t *_buckets; //哈希表
mask_t _mask; //大小
mask_t _occupied; //已占用大小
};
在上述指令中,x10 = _buckets
,而 x11
寄存器的高 32
位保存的是 _occupied
低 32
位则保存了 _mask
,x11 = occupied|mask
0x232c6f534 <+20>: and w12, w1, w11
该指令用于计算 _cmd
所传递过来的 selector
在哈希表中的起始位置。因为 _cmd
保存在 x1
寄存器中,所以 w1
寄存器则包含了 _cmd
的低 32 位信息。而 w11
寄存器保存了上面提到的 _mask
信息。通过 AND
指令我们将这两个寄存器中数值与操作结果保存到 w12
寄存器中。计算结果相当于 _cmd % table_size
。
0x232c6f538 <+24>: add x12, x10, x12, lsl #4
我们只得到了sel
的索引,我们需要得到最终的实际地址。而这正是该指令的目的。因为哈希表的_buckets
结构体都是 16
个字节,所以这里先对 x12
寄存器中的索引值左移 4
位也就是乘以 16
,然后再将其与表首地址相加后的确切 _buckets
地址信息保存到 x12
中。
buckets+((_cmd & mask)<<4)
,((_cmd & mask)<<4) = hash_key
这是bucket_t
结构体:
struct bucket_t {
#if __arm64__
MethodCacheIMP _imp;
cache_key_t _key;
};
0x232c6f53c <+28>: ldp x17, x9, [x12]
通过ldp
指令,将x12
寄存器中的_buckets
对应的信息加载到x9
和x17
寄存器中,x9 = sel
, x17 = IMP
0x232c6f540 <+32>: cmp x9, x1
0x232c6f544 <+36>: b.ne 0x232c6f54c ; <+44>
这段指令将x9
中的sel
和x1
中的_cmd
相比较if (_buckets->sel != _cmd)
如果不等,则跳转0x232c6f54c
,相等,则继续下一条指令
0x232c6f548 <+40>: br x17
跳转到x17
寄存器所指位置,也就是IMP
,方法的实现
0x232c6f54c <+44>: cbz x9,0x232c6f820 ;_objc_msgSend_uncached
x9
包含sel
信息,与0
作比较,如果等于0
就跳转到_objc_msgSend_uncached
方法进行更全面的查找,此时_buckets
是空的,意味着查找失败。否则就说明_buckets
不是空的,只是没有匹配,继续查找
0x232c6f550 <+48>: cmp x12, x10
0x232c6f554 <+52>: b.eq 0x232c6f560 ; <+64>
将 x12
寄存器中的当前 _buckets
地址与 x10
寄存器中的哈希表首地址进行比较。如果哈希桶中对应的项已经被占用但是又不是要执行的方法,则通过开地址法来继续寻找缓存该方法的桶,注意:这里是从尾部开始的(为了效率)
0x232c6f558 <+56>: ldp x17, x9, [x12, #-0x10]!
ldp
指令 x12-=16
,x12
指向新的_buckets
0x232c6f55c <+60>: b 0x232c6f540 ; <+32>
现在是一个新的_buckets
,这条指令回到0x232c6f540
,再次查找,相当是循环查找
0x232c6f560 <+64>: add x12, x12, w11, uxtw #4
x12 = buckets+(mask<<4)
,现在x12
指向表的末尾
0x232c6f564 <+68>: ldp x17, x9, [x12]
ldp
加载新的_buckets
0x232c6f568 <+72>: cmp x9, x1
0x232c6f56c <+76>: b.ne 0x232c6f574 ; <+84>
0x232c6f570 <+80>: br x17
和上面相同,检查bucket
是否匹配,跳转
0x232c6f574 <+84>: cbz x9, 0x232c6f820 ; _objc_msgSend_uncached
还是和之前一样,miss if bucket->sel == 0
0x232c6f578 <+88>: cmp x12, x10
0x232c6f57c <+92>: b.eq 0x232c6f588 ; <+104>
再次检查是否已到表头
0x232c6f580 <+96>: ldp x17, x9, [x12, #-0x10]!
0x232c6f584 <+100>: b 0x232c6f568 ; <+72>
循环查找
0x232c6f588 <+104>: b 0x232c6f820 ; _objc_msgSend_uncached
跳转到c方法
0x232c6f58c <+108>: b.eq 0x232c6f5c4 ; <+164>
nil check
,0
为nil
, 负数为tagged pointer
0x232c6f590 <+112>: adrp x10, 241366
0x232c6f594 <+116>: add x10, x10, #0x0 ; =0x0
这里加载了_objc_debug_taggedpointer_classes
的地址,即tagged pointer
主表。
0x232c6f598 <+120>: lsr x11, x0, #60
x0
的前四位保存了tagged pointer
的索引。如果需要把它用于索引,则需要将其右移60
位,这样它就变成一个0-15
的整数了。这个指令执行了位移并将索引放到x11
中。
0x232c6f59c <+124>: ldr x16, [x10, x11, lsl #3]
这里通过x11
里的索引到x10
所指向的表中查找条目。x16
寄存器现在包含了这个tagged pointer
的类。
0x232c6f5a0 <+128>: adrp x10, 241365
0x232c6f5a4 <+132>: add x10, x10, #0xed8 ; =0xed8
扩展的tagged
类执行起来也是一样的。这两条指令加载了指向扩展表的指针。
0x232c6f5a8 <+136>: cmp x10, x16
0x232c6f5ac <+140>: b.ne 0x232c6f530 ; <+16>
0x232c6f5b0 <+144>: adrp x10, 241366
0x232c6f5b4 <+148>: add x10, x10, #0x80 ; =0x80
0x232c6f5b8 <+152>: ubfx x11, x0, #52, #8
这条指令加载了扩展类的索引。它从self
中的第52
位开始,提取8
位,保存到x11
中。
0x232c6f5bc <+156>: ldr x16, [x10, x11, lsl #3]
这个索引用于在表中查找类,并存入x16
0x232c6f5c0 <+160>: b 0x232c6f530 ; <+16>
0x232c6f5c4 <+164>: mov x1, #0x0
0x232c6f5c8 <+168>: movi d0, #0000000000000000
0x232c6f5cc <+172>: movi d1, #0000000000000000
0x232c6f5d0 <+176>: movi d2, #0000000000000000
0x232c6f5d4 <+180>: movi d3, #0000000000000000
0x232c6f5d8 <+184>: ret
0x232c6f5dc <+188>: nop
以上代码是处理nil
的过程
网友评论