動態鏈接的相關結構_ZenDei技術網路在線

在瞭解了共用對象的絕對地址的引用問題後，我們基本上對動態鏈接的原理有了初步的瞭解，接下來的問題是整個動態鏈接具體的實現過程了。動態鏈接在不同的系統上有不同的實現方式。ELF的動態鏈接的實現方式會比PE的簡單一點，在這裡我們先介紹ELF的動態鏈接過程在LINUX下的實現，最後我們會專門的章節中介紹PE ...

在瞭解了共用對象的絕對地址的引用問題後，我們基本上對動態鏈接的原理有了初步的瞭解，接下來的問題是整個動態鏈接具體的實現過程了。動態鏈接在不同的系統上有不同的實現方式。ELF的動態鏈接的實現方式會比PE的簡單一點，在這裡我們先介紹ELF的動態鏈接過程在LINUX下的實現，最後我們會專門的章節中介紹PE在Windows下的動態鏈接過程和它們的區別

我們在前面的章節已經看到,動態鏈接情況下,可執行文件的裝載與靜態鏈接情況基本樣。首先操作系統會讀取可執行文件的頭部檢查文件的合法性,然後從頭部中的“ Program Header”中讀取每個“Segment”的虛擬地址、文件地址和屬性,並將它們映射到進程虛擬空間的相應位置,這些步驟跟前面的靜態鏈接情況下的裝載基本無異。在靜態鏈接情況下,操作系統接著就可以把控制權轉交給可執行文件的入口地址,然後程式開始執行,一切看起來非常直觀。

但是在動態鏈接情況下,操作系統還不能在裝載完可執行文件之後就把控制權交給可執行文件,因為我們知道可執行文件依賴於很多共用對象。這時候,可執行文件里對於很多外部符號的引用還處於無效地址的狀態,即還沒有跟相應的共用對象中的實際位置鏈接起來。所以在映射完可執行文件之後,操作系統會先啟動個動態鏈接器( Dynamic Linker)

在 Linux下,動態鏈接器ld.so實際上是一個共用對象,操作系統同樣通過映射的方式將它載入到進程的地址空間中。操作系統在載入完動態鏈接器之後,就將控制權交給動態鏈接器的入口地址(與可執行文件一樣,共用對象也有入口地址)。當動態鏈接器得到控制權之後,它開始執行一系列自身的初始化操作,然後根據當前的環境參數,開始對可執行文件進行動態鏈接工作。當所有動態鏈接工作完成以後,動態鏈接器會將控制權轉交到可執行文件的入口地址,程式開始正式執行

1. ".interp"段

那麼系統中哪個才是動態鏈接器呢,它的位置由誰決定?是不是所有的*NX系統的動態鏈接器都位於 /lib/ld.so呢?實際上,動態鏈接器的位置既不是由系統配置指定,也不是由環境參數決定,而是由ELF可執行文件決定。在動態鏈接的ELF可執行文件中,有一個專門的段叫做“ Interp”段(“ Interp”是“ Interpreter”(解釋器)的縮寫)。如果我們使用 objdump工具來查看,可以看到“ .interp”內容:

".interp"的內容很簡單，裡面保存的就是一個字元串，這個字元串就是可執行的所需要的動態鏈接器的路徑。在LINUX下，可執行文件所需要的動態鏈接器的路徑幾乎都是 “/lib/ld-linux.so.2”，其他的*.nix操作系統可能會有不同路徑。我們在後面還會介紹到各種環境下的動態鏈接器的路徑。在LINUX系統中，/lib/ld-linux.so.2通常是一個軟鏈接，比如在我的機器中，它指向/lib/ld-linux.so.2，這個才是真正的動態鏈接器，在linux中，操作系統在對可執行文件所需要的相應動態連接器，即“.interp”段指定的路徑的共用對象；

動態鏈接器在linux下是glibc的一部分，也就是屬於系統庫級別的，它的版本號往往跟系統的Glibc庫版本號是一樣的，比如我的系統中安裝的是glibc 2.6.1，那麼相應的動態鏈接庫就是/lib/ld-2.6.1.so。當系統中的Glibc庫更新或者安裝其他版本的時候，/lib/ld-linux.so.2 這個軟鏈接就會指向新的動態鏈接器，而可執行文件本身不需要修改 ".interp" 中的動態鏈接器路徑來適應系統的升級

我們往往可以用這個命令來查看一個可執行文件所需要的動態鏈接器的路徑，在linux下，往往是這個結果：

readelf -l a.out | grep interpreter
[Requeseting program interpreter: /lib/ld-linux.so.2]

而當我們在FreeBSD 4.6.2 下執行這個命令時，結果是：

readelf -l a.out | grep interpreter

64 位的linux下的可執行文件是：

readelf -l a.out | grep interpreter

2. “.dynamic”段

類似於“.interp”這樣的段，ELF中還有幾個段也是專門用於動態鏈接的，比如 ".dynamic" 段和 ".dynsym"段等。要瞭解動態鏈接器如何完成鏈接過程，跟前面一樣，從瞭解ELF文件中跟動態鏈接相關的結構入手將會是一個很好的途徑。ELF文件中跟動態鏈接相關的段有好幾個，相互之間的關係也比較複雜，我們先從 ".dynamic" 段入手

動態鏈接ELF中最重要的結構應該是“ .dynamic”段,這個段裡面保存了動態鏈接器所需要的基本信息,比如依賴於哪些共用對象、動態鏈接符號表的位置、動態鏈接重定位表的位置、共用對象初始化代碼的地址等。“ .dynamic”段的結構很經典,就是我們已經碰到過的ELF中眼熟的結構數組,結構定義在“elf.h”中:

typedef struct {
    Elf32_Sword d_tag;
    union {
        Elf32_Word d_val;
        Elf32_Addr d_ptr;
    } d_un;
} Elf32_Dyn;

Elf32_Dyn 結構由一個類型值加上一個附加的數值或指針，對於不同類型，後面附加的數值或者指針有著不同含義。我們這裡列舉幾個比較常見的類型值（這些值都是定義在“elf.h”裡面的巨集），如表7-2所示：

表7-2中只列出了一部分定義，還有一些不太常用的定義我們就暫且忽略，具體可以參考LSB手冊和elf.h的定義。從上面給出的定義來看，“.dynamic”段裡面保存的信息有點像elf文件頭，只是我們看到的elf文件頭中保存的是靜態鏈接時的相關信息，比如靜態鏈接時使用到的符號表、重定位表等，這裡換成了動態鏈接下所使用的相應信息了。所以，“.dynamic”段可以看成動態鏈接下的ELF文件的“文件頭”。使用readelf工具可以查看 ".dynamic" 段的內容

$ readelf -d lib.so

另外linux還提供了一個命令用來查看一個程式主模塊或一個共用庫依賴於哪些共用庫：

動態符號表

為了完成動態鏈接,最關鍵的還是所依賴的符號和相關文件的信息。我們知道在靜態鏈接中,有一個專門的段叫做符號表“.symtab”( Symbol Table),裡面保存了所有關於該目標文件的符號的定義和引用。動態鏈接的符號表示實際上它跟靜態鏈接十分相似,比如前面例子中的 Program1程式依賴於 Lib.so,引用到了裡面的 foobar()函數。那麼對於 Program1來說,我們往往稱 ProgramI導入( Import)了 foobar函數, foobar是 Program1的導入函數(import Function):而站在Lib.so的角度來看,它實際上定義了 foobar函數,並且提供給其他模塊使用,我們往往稱Lib.so導出( Export)了 foobar函數, foobar是Lbso的導出函數(Export Function)。把這種導入導出關係放到靜態鏈接的情形下,我們可以把它們看作普通的函數定義和引用。

為了表示動態鏈接這些模塊之間的符號導入導出關係，ELF專門有一個叫做動態符號表（Dynamic symbol table）的段用來保存這些信息，這個段的段名通常叫做“.dynsym”(Dynamic Symbol)。與 “.sysmtab”不同的是，".dynsym" 只保存了與動態鏈接相關的符號，對於那些模塊內部的符號，比如模塊私有變數則不保存。很多時候動態鏈接的模塊同時擁有“.dynsym” 和 ".sysmtab"中往往保存了所有符號，包括 “.dynsym” 中的符號

與 “.sysmtab” 類似，動態符號表也需要一些輔助的表，比如用於保存符號名的字元串表。靜態鏈接的時候叫做符號字元串“.strtab” (Striing Table)，在這裡就是動態符號字元串表“.dynstr” (Dynamic String Table)；由於動態鏈接下，我們需要在程式運行時查找符號，為了加快符號的查找過程，往往還有輔助的符號哈希表（“.hash”）。我們可以用readelf工具來查看elf文件的動態符號表及哈希表：

readelf -sD lib.so

動態鏈接符號表的結構與靜態鏈接的符號表幾乎一樣，我們可以簡單的將導入韓式看作是對其他目標文件中函數的引用：把導出函數看作是在本目標文件定義的函數就可以了；

3. 動態鏈接重定位表

共用對象需要重定位的主要原因是導入符號的存在。在動態鏈接下，無論是可執行文件或共用對象，一旦它依賴於其他共用對象，也就是說有導入的符號時，那麼它的代碼或數據中就會有對於導入符號的引用。在編譯時這些導入符號的地址未知，在靜態鏈接中，這些未知的地址引用在最終鏈接時被修正。但是在動態鏈接中，導入符號的地址在運行時才確定，所以需要在運行時將這些導入符號的引用修正，即需要重定位；

我們在前面地址無關章節中也提到過，動態鏈接的可執行文件使用的是PIC方法，但這不能改變它需要重定位的本質。對於動態鏈接來說，如果一個共用對象不是以PIC模式編譯的，那麼毫無疑問，它是需要在裝載時被重定位的：如果一個共用對象是PIC模式編譯的，那麼它還需要再裝載時進行重定位嗎？是的，PIC的共用對象也是需要重定位的；

對於使用PIC技術的可執行文件或共用對象來說,雖然它們的代碼段不需要重定位(因為地址無關),但是數據段還包含了絕對地址的引用,因為代碼段中絕對地址相關的部分被分離了出來,變成了GOT,而GOT實際上是數據段的一部分。除了GOT以外,數據段還可能包含絕對地址引用,我們在前面的章節中已經舉例過了。

動態鏈接重定位的相關結構

共用對象的重定位與我們在前面“靜態鏈接”中分析過的目標文件的重定位十分類似,唯一有區別的是目標文件的重定位是在靜態鏈接時完成的,而共用對象的重定位是在裝載時完成的。在靜態鏈接中,目標文件裡面包含有專門用於表示重定位信息的重定位表,比如“rel.text”表示是代碼段的重定位表,“rel.data”是數據段的重定位表。

動態鏈接的文件中,也有類似的重定位表分別叫做“ .rel.dyn”和“.rel. plt”,它們分別相當於“.rel.text”和“.rel.data”“.rel .dyn”實際上是對數據引用的修正,它所修正的位置位於“.got”以及數據段;而“ .rel.plt”是對函數引用的修正,它所修正的位置位於“.got.plt”。我們可以使用 readelf來查看一個動態鏈接的文件的重定位表

可以看到Lib.c中兩個導入函數“printf” 和“sleep” 從“.rel.plt”到了“.rel.dyn”，並且類型也從R_386_JUMP_SLOT變成了R_386_PC32

而R_386_RELATIVE類型多出了一個偏移為0x0000042c的入口，這個入口是什麼呢？通過對Lib.so 的反彙編可以知道，這個入口用來修正給printf的第一個參數，即我們的字元串常量“Printing from Lib.so %d\n”的地址。為什麼這個字元串常量的地址在PIC時不需要重定位而在非PIC時需要重定位呢？很明顯，PIC時，這個字元串可以看做是普通的全局變數，它的地址是可以通過PIC中的相對當前指令的位置加上一個固定偏移計算出來的：而在非PIC中，代碼段不再使用這種相對於當前指令的PIC方法，而是採用絕對地址定址，所以它需要重定位；

動態鏈接時進程堆棧初始化信息

站在動態鏈接器的角度看,當操作系統把控制權交給它的時候,它將開始做鏈接丁作,那麼至少它需要知道關於可執行文件和本進程的一些信息,比如可執行文件有幾個段(“ Segment”)、每個段的屬性、程式的入口地址(因為動態鏈接器到時候需要把控制權交給可執行文件)等。這些信息往往由操作系統傳遞給動態鏈接器,保存在進程的堆棧裡面。我們在前面提到過,進程初始化的時候,堆棧裡面保存了關於進程執行環境和命令行參數等信息。事實上,堆棧裡面還保存了動態鏈接器所需要的一些輔助信息數組( Auxiliary Vector)。輔助信息的格式也是一個結構數組,它的結構被定義在“elf.h”

typedf struct
{
    uint32_t a_type;
    union {
        uint32_t a_val;
    } a_un;
} Elf32_auxv_t;

是不是已經對這種結構很熟悉了？沒錯，跟前面的“.dynamic”段裡面的結構如出一轍。先是一個32位類型的值，後面是一個32位的數值部分，你很可能很奇怪為什麼要用一個union把後面的32位數值包裝起來，事實上，這個union沒啥用，只是歷史遺留而已，可以當做不存在。我們摘錄幾個比較重要的類型值，這幾個類型值都是比較常見的，而且是動態鏈接器在啟動時所需要的，如表7-3所示：