Mach-O 的動態連結(Lazy Bind 機制)

聽雲APM發表於2016-12-12

原文出自【聽雲技術部落格】:http://blog.tingyun.com/web/article/detail/1347

動態連結

要解決空間浪費和更新困難這兩個問題最簡單的方法就是把程式的模組相互分割開來,形成獨立的檔案,而不再將它們靜態的連結在一起。簡單地講,就是不對那些組成程式的目標檔案進行連結,等到程式要執行時才進行連結。也就是說,把連結過程推遲到了執行時再進行,這就是 動態連結(Dynamic Linking)的思想。

延遲繫結(PLT)

動態連結比靜態連結效能低,主要原因是動態連結下對於全域性和靜態的資料訪問都要進行復雜的GOT定位,間接定址;對於模組間的呼叫也要先定位GOT,間接跳轉, 程式的執行速度一定會減慢。 另外因為動態連結是在執行時完成連結的工作:在程式開始執行時,動態連結器都要進行一次連結工作,動態連結器會 search 並 load 所需要的 共享物件,然後進行符號查詢 地址重定位,這一系列動作會減慢程式的啟動速度。

PLT 就是為了優化動態連結效能而存在,基本思想就是 當函式第一次被呼叫到時才進行繫結(符號查詢,重定位),如果沒有用到則不進行 bind。 這樣在程式執行時,模組間的函式呼叫都沒有進行 bind , 而是需要呼叫時才由 動態連結器來負責 bind 。這樣可以加速程式的啟動速度。

Mach-O Lazy Bind

Mach-O 檔案通過dyld 載入的時候並沒有確定每一個函式的具體地址在哪裡,而是在真正呼叫該函式的時候通過 過程連結表(procedure linkage table),簡稱 PLT,來進行一次lazybind。

結合Mach-O 檔案的分析與程式碼的除錯簡單的分析一下。

原始碼如下:

1.png

分別在兩個printf函式處下 斷點。

第一個呼叫printf函式

2.png

在0x100000f52 \<+34>行處通過callq 0x100000f76 來呼叫printf。

執行callq指令 之後程式碼跳轉到這裡:

2-2.png

這裡的jmpq 要跳轉到 0x0000000100000F8C ,這個地址是從 —Data , —la-symbol-ptr 中的Lazy Symbol Pointers 中獲取到的。

3.png

通過lldb 的命令 檢視 0x100001010處的地址 獲取了同樣的值。

通過—stub—helper進行lazybind

在Mach-O 中每一個Symbol Stub 可能有以下兩種行為其中之一:跳轉到函式的指令,執行函式體,通過動態動態庫連結器查詢函式的Symbol,然後執行函式體

檢視 —stubs的Section 資料,發現只有一個函式就是 printf

4.png

這裡的Data 其實就是上面看到的 jmpq 的程式碼。執行之後程式碼跳轉到了這樣的程式碼片段。

5.png

這裡就是通過 —stub-helper來呼叫 dyld-stubbinder函式來計算printf 函式的真是地址。 通過下面的 資訊可以看出來,jmpq 0x100000f7c ,就是在壓如入引數0x0 (函式的link 的時候給的編號) 之後跳轉到Section的起始處,呼叫 binder(一段彙編程式碼, 作用就是計算具體的函式地址,並呼叫printf 函式)

6.png

第二次呼叫printf 函式

7.png

執行指令之後發現和第一次呼叫printf 已經不一樣了。

8.png

再一次檢視 0x100001010 處記憶體值。已經很第一次不同了,也就是說, —Data, —la-symbol-ptr 中指向printf地址的值已經發生了變化,指向了 printf的指令。

這就證明了,延遲繫結只會在第一次呼叫的時候發生。整個流程與 linux中的PLT 和GOT 在實現邏輯上基本相同,只是實現程式碼不同而已。

參考《Mac OS X and iOS Internals》、《連結,裝載與庫》

相關文章