動態鏈接的確有很多優勢,比靜態鏈接要靈活得多,但它是以犧牲一部分性能為代價的。據統計ELF程式在靜態鏈接下要比動態庫稍微快點,大約為1%~5%,當然這取決於程式本身的特性及運行環境等。我們知道動態鏈接比靜態鏈接慢的主要原因是動態鏈接下對於全局和靜態的數據訪問都要進行複雜的GOT定位,然後間接定址;對 ...
動態鏈接的確有很多優勢,比靜態鏈接要靈活得多,但它是以犧牲一部分性能為代價的。據統計ELF程式在靜態鏈接下要比動態庫稍微快點,大約為1%~5%,當然這取決於程式本身的特性及運行環境等。我們知道動態鏈接比靜態鏈接慢的主要原因是動態鏈接下對於全局和靜態的數據訪問都要進行複雜的GOT定位,然後間接定址;對於模塊間的調用也要先定位GOT,然後再進行間接跳轉,如此一來,程式的運行速度必定會減慢。另外一個減慢運行速度的原因是動態鏈接的鏈接工作在運行時完成,即程式開始執行時,動態鏈接器都要進行一次鏈接工作,正如我們上面提到的,動態鏈接器會尋找並裝載所需要的共用對象,然後進行符號査找地址重定位等工作,這些工作勢必減慢程式的啟動速度。這是影響動態鏈接性能的兩個主要問題,我們將在這一節介紹優化動態鏈接性能的一些方法。
延遲綁定實現
在動態鏈接下,程式模塊之間包含了大量的函數引用(全局變數往往比較少,因為大量的全局變數會導致模塊之間耦合度變大),所以在程式開始執行前,動態鏈接會耗費不少時間用於解決模塊之間的函數引用的符號查找以及重定位,這也是我們上面提到的減慢動態鏈接性能的第二個原因。不過可以想象,在一個程式運行過程中,可能很多函數在程式執行完時都不會被用到,比如一些錯誤處理函數或者是一些用戶很少用到的功能模塊等,如果一開始就把所有函數都鏈接好實際上是一種浪費。所以ELF採用了一種叫做延遲綁定(Lazy Binding)的做法,基本的思想就是當函數第一次被用到時才進行綁定(符號査找、重定位等),如果沒有用到則不進行綁定。所以程式開始執行時,模塊間的函數調用都沒有進行綁定,而是需要用到時才由動態鏈接器來負責綁定。這樣的做法可以大大加快程式的啟動速度,特別有利於一些有大量函數引用和大量模塊的程式。
ELF使用PLT( Procedure Linkage Table)的方法來實現,這種方法使用了一些很精巧的指令序列來完成。在開始詳細介紹PLT之前,我們先從動態鏈接器的角度設想一下：假設 liba.so需要調用ibc.so中的bar(函數,那麼當 liba. so中第一次調用bar()時,這時候就需要調用動態鏈接器中的某個函數來完成地址綁定工作,我們假設這個函數叫做 lookup(),那麼 lookup)需要知道哪些必要的信息才能完成這個函數地址綁定工作呢?我想答案很明顯, lookup至少需要知道這個地址綁定發生在哪個模塊,哪個函數?那麼我們可以假設lookup的原型為 lookup( module, function),這兩個參數的值在我們這個例子中分別為 liba.so和bar()。在Glbc中,我們這裡的 lookup函數真正的名字叫 _dl_ runtime_resolve()。
當我們調用某個外部模塊的函數時，如果按照通常的做法應該是通過GOT中相應的項進行間接跳轉。PLT為了實現延遲綁定，在這個過程中間又增加了一層間接跳轉。調用函數並不直接通過GOT跳轉，而是通過一個叫做PLT項的結構來進行跳轉。每個外部函數在PLT中都有一個相應的項，比如bar()函數在PLT中的項的地址我們稱之為bar@plt。讓我們來看看bar@plt的實現
bar@plt的第一條指令是一條通過GOT間接跳轉的指令。bar@GOT表示GOT中保存bar()這個函數相應的項。如果鏈接器在初始化階段已經初始化該項,並且將bar()的地址填入該項,那麼這個跳轉指令的結果就是我們所期望的,跳轉到bar(0,實現函數正確調用但是為了實現延遲綁定,鏈接器在初始化階段並沒有將bar()的地址填入到該項,而是將上面代碼中第二條指令“ push n”的地址填入到bar@GOT中,這個步驟不需要查找任何符號,所以代價很低。很明顯,第條指令的效果是跳轉到第二條指令,相當於沒有進行任何操作。第二條指令將一個數字n壓入堆棧中,這個數字是bar這個符號引用在重定位表“ rel. plt”中的下標接著又是一條push指令將模塊的D壓入到堆棧,然後跳轉到dl_ runtime resolve這實際上就是在實現我們前畝提到的 lookup( module, function)這個函數的調用:先將所需要決議符號的下標壓入堆棧,再將模塊ID壓入堆棧,然後調用動態鏈接器的d_ runtime_ resolve()函數來完成符號解析和重定位作。 dl_runtime_resolve在進行一系列工作以後將bar(的真正地址填入到bar@GOT中
一旦bar()這個函數被解析完成，當我們再次調用bar@plt時，第一條jmp指令就能夠跳轉到真正的bar()函數中，bar()函數返回的時候會根據堆棧裡面保存的EIP直接返回調用者，而不會再繼續執行bar()plt中第二條指令的開始的那段代碼，那段代碼指揮在符號未被解析的時候執行一次；
上面描述的是PLT的基本原理，PLT的真正實現要比它的結構複雜一些，ELF將GOT拆分成兩個表".got"和"".got.plt"。其中"".got"用來保存全局變數的引用地址。".got.plt"用來保存函數引用的地址，也就是說，所有對於外部函數的引用全部被分離出來放到了 ".got.plt"中。另外 ".got.plt"還有一個特殊的地方就是它的前三項是有特殊意義的，分別含義如下：
- 第一項保存的是 ".dynamic" 段的地址，這個段描述了本模塊動態鏈接的相關信息，我們在後面還會介紹 ".dynamic"段
- 第二項保存的是本模塊的ID
- 第三項保存的是_dl_runtime_resolve()的地址
其中第二項和第三項由動態鏈接器在轉載共用模塊的時候負責將它們初始化。".got.plt"的其餘項分別對應每一個外部函數的引用。PLT的結構也與我們示例中的PLT稍有不同，為了減少代碼的重覆，ELF把上面的例子中的最後兩條指令放在PLT中的第一項，並且規定每一項是16個位元組，剛好用來存放3條指令，實際上的PLT的基本結構如圖所示：
實際上的PLT結構如下：
PLT0:
push *(GOT + 4)
jump *(GOT + 8)
....
bar@plt:
jmp *(bar@GOT)
push n
jump PLT0PLT在ELF文件中以獨立代碼的段存放，段名通常稱為 ".plt"，因為它本身就是一些地址無關的代碼，所以可以跟代碼段一起合併成同一個可讀可執行的""Segment"被裝載到記憶體中
