➠更多技術乾貨請戳：聽雲博客 動態鏈接 要解決空間浪費和更新困難這兩個問題最簡單的方法就是把程式的模塊相互分割開來，形成獨立的文件，而不再將它們靜態的鏈接在一起。簡單地講，就是不對那些組成程式的目標文件進行鏈接，等到程式要運行時才進行鏈接。也就是說，把鏈接過程推遲到了運行時再進行，這就是 _動態鏈接 ...
動態鏈接
要解決空間浪費和更新困難這兩個問題最簡單的方法就是把程式的模塊相互分割開來，形成獨立的文件，而不再將它們靜態的鏈接在一起。簡單地講，就是不對那些組成程式的目標文件進行鏈接，等到程式要運行時才進行鏈接。也就是說，把鏈接過程推遲到了運行時再進行，這就是 _動態鏈接（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 文件的分析與代碼的調試簡單的分析一下。
源代碼如下：
分別在兩個printf函數處下 斷點。
第一個調用printf函數
在0x100000f52 \<+34\>行處通過callq 0x100000f76 來調用printf。
執行callq指令 之後代碼跳轉到這裡：
這裡的jmpq 要跳轉到 0x0000000100000F8C ，這個地址是從 —Data , —la-symbol-ptr 中的Lazy Symbol Pointers 中獲取到的。
通過lldb 的命令 查看 0x100001010處的地址 獲取了同樣的值。
通過—stub—helper進行lazybind
在Mach-O 中每一個Symbol Stub 可能有以下兩種行為其中之一：跳轉到函數的指令，執行函數體，通過動態動態庫鏈接器查找函數的Symbol，然後執行函數體
查看 —stubs的Section 數據，發現只有一個函數就是 printf
這裡的Data 其實就是上面看到的 jmpq 的代碼。執行之後代碼跳轉到了這樣的代碼片段。
這裡就是通過 —stub-helper來調用 dyld-stubbinder函數來計算printf 函數的真是地址。 通過下麵的 信息可以看出來，jmpq 0x100000f7c ,就是在壓如入參數0x0 （函數的link 的時候給的編號） 之後跳轉到Section的起始處，調用 binder（一段彙編代碼， 作用就是計算具體的函數地址，並調用printf 函數）
第二次調用printf 函數
執行指令之後發現和第一次調用printf 已經不一樣了。
再一次查看 0x100001010 處記憶體值。已經很第一次不同了，也就是說， —Data, —la-symbol-ptr 中指向printf地址的值已經發生了變化，指向了 printf的指令。
這就證明瞭，延遲綁定只會在第一次調用的時候發生。整個流程與 linux中的PLT 和GOT 在實現邏輯上基本相同，只是實現代碼不同而已。
參考《Mac OS X and iOS Internals》、《鏈接，裝載與庫》
原文鏈接：http://blog.tingyun.com/web/article/detail/1347
