objc_msgSend的匯編理解

了解OC語言Runtime機(jī)制的開發(fā)者都知道,幾乎所有的方法調(diào)用都會轉(zhuǎn)化成objc_msgSend(void /* id self, SEL op, ... */ )的調(diào)用,今天探索一下ARM64架構(gòu)下的objc_msgSend的匯編實(shí)現(xiàn),objc_msgSend 用匯編語言進(jìn)行實(shí)現(xiàn),具體理由有兩個:首先純 C 語言無法實(shí)現(xiàn)這么一個函數(shù):接收不定個數(shù)且未知類型的參數(shù)作為入?yún)⑻D(zhuǎn)至任意函數(shù)指針(即調(diào)用實(shí)現(xiàn));其次,執(zhí)行速度對 objc_msgSend 來說非常重要,匯編語言能最大化提升該項(xiàng)指標(biāo)。具體可以看這個,為什么objc_msgSend必須用匯編

image

在真機(jī)環(huán)境下,設(shè)置一個符號斷點(diǎn)即可查看objc_msgSend的匯編實(shí)現(xiàn)
image

圖片來源
objc_msgSend主要有以下幾個步驟:

  1. 通過isa獲取傳入的對象的類
  2. 獲取這個類的方法緩存表
  3. 通過傳入的selector,在緩存中查找方法
  4. 如果緩存中沒有,調(diào)用C函數(shù)
  5. 跳到這個方法的IMP

下面對匯編程序逐行分析

0x232c6f520 <+0>:   cmp    x0, #0x0                  ; =0x0 
0x232c6f524 <+4>:   b.le   0x232c6f58c               ; <+108>   

判斷x0nil還是tagged pointer,等于0nil,小于0tagged pointer

0x232c6f528 <+8>:   ldr    x13, [x0]  

x0中所表示的selfisa地址放到x13寄存器中

0x232c6f52c <+12>:  and    x16, x13, #0xffffffff8

當(dāng)前對象邏輯與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架構(gòu)下使用 non-pointer isa技術(shù),和之前的isa相比,isa字段不僅存放了Class的信息,還存放了其他信息(上面的代碼塊),這里通過AND運(yùn)算除去低位的冗余信息將最終的Class的地址放入x16寄存器中

0x232c6f530 <+16>:  ldp    x10, x11, [x16, #0x10]

該指令會將Class中的方法緩存哈希表bucket加載到x10x11 兩個寄存器中。ldp指令會將有效的內(nèi)存信息加載到該指令的前兩個寄存器中,而第三個參數(shù)則對應(yīng)該信息的內(nèi)存地址,在該例中緩存哈希表地址為x16寄存器中地址偏移16后所處的位置,

struct objc_class : objc_object {
    // Class ISA;              // 8
    Class superclass;          // 8
    cache_t cache;             // fpointer and vtable
    class_data_bits_t bits;    // 
};

ISAsuperclass 各占8個字節(jié),所以偏移16個字節(jié)后,指向cache_t cache

struct cache_t {
    struct bucket_t *_buckets;  //哈希表
    mask_t _mask;               //大小
    mask_t _occupied;           //已占用大小
};

在上述指令中,x10 = _buckets,而 x11 寄存器的高 32 位保存的是 _occupied32 位則保存了 _mask ,x11 = occupied|mask

0x232c6f534 <+20>:  and    w12, w1, w11

該指令用于計(jì)算 _cmd 所傳遞過來的 selector 在哈希表中的起始位置。因?yàn)?_cmd 保存在 x1 寄存器中,所以 w1 寄存器則包含了 _cmd 的低 32 位信息。而 w11 寄存器保存了上面提到的 _mask 信息。通過 AND 指令我們將這兩個寄存器中數(shù)值與操作結(jié)果保存到 w12 寄存器中。計(jì)算結(jié)果相當(dāng)于 _cmd % table_size。

0x232c6f538 <+24>:  add    x12, x10, x12, lsl #4

我們只得到了sel的索引,我們需要得到最終的實(shí)際地址。而這正是該指令的目的。因?yàn)楣1淼?code>_buckets結(jié)構(gòu)體都是 16 個字節(jié),所以這里先對 x12 寄存器中的索引值左移 4 位也就是乘以 16 ,然后再將其與表首地址相加后的確切 _buckets 地址信息保存到 x12 中。
buckets+((_cmd & mask)<<4),((_cmd & mask)<<4) = hash_key
這是bucket_t結(jié)構(gòu)體:

struct bucket_t {
#if __arm64__
    MethodCacheIMP _imp;
    cache_key_t _key;
};
0x232c6f53c <+28>:  ldp    x17, x9, [x12]

通過ldp指令,將x12寄存器中的_buckets對應(yīng)的信息加載到x9x17寄存器中,x9 = sel, x17 = IMP

0x232c6f540 <+32>:  cmp    x9, x1
0x232c6f544 <+36>:  b.ne   0x232c6f54c               ; <+44>

這段指令將x9中的selx1中的_cmd相比較if (_buckets->sel != _cmd)如果不等,則跳轉(zhuǎn)0x232c6f54c,相等,則繼續(xù)下一條指令

0x232c6f548 <+40>:  br     x17

跳轉(zhuǎn)到x17寄存器所指位置,也就是IMP,方法的實(shí)現(xiàn)

0x232c6f54c <+44>:  cbz    x9,0x232c6f820           ;_objc_msgSend_uncached

x9 包含sel信息,與0作比較,如果等于0就跳轉(zhuǎn)到_objc_msgSend_uncached方法進(jìn)行更全面的查找,此時_buckets是空的,意味著查找失敗。否則就說明_buckets不是空的,只是沒有匹配,繼續(xù)查找

0x232c6f550 <+48>:  cmp    x12, x10
0x232c6f554 <+52>:  b.eq  0x232c6f560               ; <+64>

x12 寄存器中的當(dāng)前 _buckets 地址與 x10 寄存器中的哈希表首地址進(jìn)行比較。如果哈希桶中對應(yīng)的項(xiàng)已經(jīng)被占用但是又不是要執(zhí)行的方法,則通過開地址法來繼續(xù)尋找緩存該方法的桶,注意:這里是從尾部開始的(為了效率)

0x232c6f558 <+56>:  ldp    x17, x9, [x12, #-0x10]!

ldp指令 x12-=16,x12指向新的_buckets

0x232c6f55c <+60>:  b      0x232c6f540               ; <+32>

現(xiàn)在是一個新的_buckets,這條指令回到0x232c6f540,再次查找,相當(dāng)是循環(huán)查找

    0x232c6f560 <+64>:  add    x12, x12, w11, uxtw #4

x12 = buckets+(mask<<4),現(xiàn)在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是否匹配,跳轉(zhuǎn)

    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>

循環(huán)查找

0x232c6f588 <+104>: b      0x232c6f820               ; _objc_msgSend_uncached

跳轉(zhuǎn)到c方法

0x232c6f58c <+108>: b.eq   0x232c6f5c4               ; <+164>

nil check,0nil, 負(fù)數(shù)為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的整數(shù)了。這個指令執(zhí)行了位移并將索引放到x11中。

0x232c6f59c <+124>: ldr    x16, [x10, x11, lsl #3]

這里通過x11里的索引到x10所指向的表中查找條目。x16寄存器現(xiàn)在包含了這個tagged pointer的類。

0x232c6f5a0 <+128>: adrp   x10, 241365
0x232c6f5a4 <+132>: add    x10, x10, #0xed8          ; =0xed8 

擴(kuò)展的tagged類執(zhí)行起來也是一樣的。這兩條指令加載了指向擴(kuò)展表的指針。

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

這條指令加載了擴(kuò)展類的索引。它從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的過程

參考

Dissecting objc_msgSend on ARM64

Why objc_msgSend Must be Written in Assembly

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

友情鏈接更多精彩內(nèi)容