目錄

1. 動態鏈接的意義 2. 地址無關代碼: PIC 3. 延遲版定(PLT Procedure Linkage Table) 4. 動態鏈接相關結構 5. 動態鏈接的步驟和實現 6. Linux動態鏈接器實現 7. 顯式運行時鏈接 8. 共享庫系統路徑 && 默認加載順序

?

1. 動態鏈接的意義

1. 靜態鏈接對內存和磁盤的浪費很嚴重，在靜態鏈接中，C語言靜態庫是很典型的占用空間的例子 2. 靜態鏈接對程序的更新、部署、發布會造成嚴重的麻煩

為了解決這些問題，最好的思路就是把程序的模塊相互分割開來，形成獨立的文件，而不再將它們靜態地鏈接在一起。簡單來說，就是不對那些組成程序的目標文件進行鏈接，等到程序要運行時才進行鏈接，也就是說，把鏈接這個過程推遲到了運行時再進行，這就是"動態鏈接(dynamic linking)"的基本思想

0x1: 動態鏈接的優點

1. 多個進程使用到同一個動態鏈接庫文件，只要在內存中映射一份ELF .SO文件即可，有效地減少了進程的內存消耗2. 減少物理頁面的換入換出(減少page out、page in操作)3. 增加CPU緩存的命中率，因為不同進程間的數據和指令訪問都集中在了同一個共享模塊上4. 使程序的升級更加容易，在升級程序庫或共享某個模塊時，只要簡單地將舊的目標文件覆蓋掉，而無須將所有的程序再重新鏈接一遍。當程序下一次運行的時候，新版本的目標文件會被自動裝載到內存并鏈接起來，程序就完成了升級的操作5. 程序可擴展性和兼容性 使用動態鏈接技術，程序在運行時可以動態地選擇加載各種程序模塊，即插件技術(Plug-in)1) 程序按照一定的規則制定好程序的接口，第三方開發者可以按照這種接口來編寫符合要求的動態鏈接文件，該程序可以動態地載入各種由第三方開發的模塊，在程序運行時動態地鏈接，實現程序功能的擴展。典型地如php的zend擴展、iis的filter/extension、apache的mod模塊2) 動態鏈接還可以加強程序的兼容性。一個程序在不同的平臺運行時可以動態地鏈接到由操作系統提供的動態鏈接庫，這些動態鏈接庫在程序和操作系統之間增加了一個中間層，從而消除了程序對不同平臺之間依賴的差異性

0x2: 動態鏈接文件的類別

動態鏈接涉及運行時的鏈接及多個文件的裝載，必須要有操作系統的支持，因為動態鏈接的情況下，進程的虛擬地址空間的分布會比靜態鏈接的情況下更為復雜，還需要考慮到一些存儲管理、內存共享、進程線程等機制的考慮

1. Linux 在Linux系統中，ELF動態鏈接文件被稱為動態共享對象(DSO Dynamic Shared Objects)，一般以".so"為擴展名 常用的C語言庫的運行庫glibc，它的動態鏈接形式的版本保存在"/lib/libc.so"、"/lib64/libc.so"。整個系統只保留一份C語言庫的動態鏈接文件，而所有的由C語言編寫的、動態鏈接的程序都可以在運行時使用它，當程序被裝載時，系統的動態鏈接器會將程序所需的所有動態鏈接庫(最基本的就是libc.so)裝載到進程的地址空間，并且將程序中所有未決議的符號綁定到相應的動態鏈接庫中，并進行重定位工作2. Windows 在Windows系統中，動態鏈接文件被稱為動態鏈接庫(Dynamic Linking Library)，一般以".dll"為擴展名

Relevant Link:

?

2. 地址無關代碼: PIC

1. 可執行文件在編譯時可以確定自己在進程虛擬地址空間中的位置，因為可執行文件往往都是第一個被加載的文件，它可以選擇一個固定的位置1) Linux: 0x080400002) Windows: 0x00400002. 共享對象在編譯時不能假設自己在進程虛擬地址空間中的位置

0x1: 裝載時重定位

Linux和GCC支持2種重定位的方法

1. 鏈接時重定位(Link Time Relocation) -shared -fPIC 在程序鏈接的時候就將代碼中對絕對地址的引用重定位為實際的地址2. 裝載時重定位(Load Time Relocation) -shared 程序模塊在編譯時目標地址不確定而需要在裝載時將模塊重定位

0x2: 地址無關代碼

裝載時重定位是解決動態模塊中有絕對地址引用的方法之一，但是還存在一個問題，指令部分無法在多個進程間共享，為了解決這個問題，一個基本思想就是把指令中那些需要被修改的部分分離出來，跟數據部分放在一起，這樣指令就可以保持不變，而數據部分可以在每個進程中擁有一個副本，這種方案就是地址無關代碼(PIC Position-Independent Code)

我們把共享對象模塊中的地址引用按照模塊內部引用/模塊外部引用、指令引用/數據訪問分為4類

/* pic.c */ static int a; extern int b; extern void ext();void bar() {//Type2: Inner-module data access(模塊內數據訪問)a = 1;//Tyep4: Inter-module data access(模塊間數據訪問)b = 2; }void foo() {//Type1: Inner-module call(模塊內指令引用) bar();//Type3: Inter-module call() ext(); }

值得注意的是，當編譯器在編譯pic.c時，它并不能確定變量b、函數ext()是模塊外部還是模塊內部的，因為它們有可能被定義在同一個共享對象的其他目標文件中，所以編譯器只能把它們都當作模塊外部的函數和變量來處理

Type1: Inner-module call(模塊內指令引用)

這是最簡單的一種情況，被調用的函數與調用者都處于同一個模塊，它們之間的相對位置是固定的，對于現代操作系統來說，模塊內部跳轉、函數調用都可以是"相對地址調用"、或者是"基于寄存器的相對調用"，所以對于這種指令是不需要重定位的，只要模塊內的相對位置不變，則模塊內的指令調用就是地址無關的

Type2: Inner-module data access(模塊內數據訪問)

我們知道，一個模塊前面一般是若干個頁的代碼，后面緊跟著若干個頁的數據，這些頁之間的相對位置是固定的，所以只需要相對于當前指令加上"固定的偏移量"就可以訪問到模塊內部數據了

Type3: Inter-module call()

GOT實現指令地址無關的方式和GOT實現模塊間數據訪問的方式類似，唯一不同的是，GOT中的項保存的是目標函數的地址，當模塊要調用目標函數時，可以通過GOT中的項進行間接跳轉

Tyep4: Inter-module data access(模塊間數據訪問)

模塊間的數據訪問比模塊內部稍微麻煩一點，因為模塊間的數據訪問目標地址要等到裝載時才能確定。而我們要達到代碼地址無關的目的，最基本的思想就是把和地址相關的部分放到數據段中，ELF的做法是在數據段里建立一個指向這些變量的指針數組，也被稱為全局偏移表(global offset table GOT)，當代碼需要引用到該全局變量時，可以通過GOT中相對應的項進行間接引用。
鏈接器在裝載動態模塊的時候會查找每個變量所在的地址，然后填充GOT中的各個項，以確保每個指針所指向的地址正確，由于GOT本身是放在數據段的，所以它可以在模塊裝載時被修改，并且每個進程都可以有獨立的副本，相互不受影響。
綜上所述，地址無關代碼的實現方式如下

1. 模塊內部1) 指令跳轉、調用: 相對跳轉和調用2) 數據訪問: 相對地址訪問 2. 模塊外部1) 指令跳轉、調用: 間接跳轉和調用(GOT)2) 數據訪問: 間接訪問(GOT)

使用GCC產生地址無關代碼很簡單，只需要使用"-fPIC"參數即可

區分一個DSO是否為PIC的方法很簡單，輸入以下指令

readelf -d hook.so | grep TEXTREL /* 1. PIC PIC的DSO是不會包含任何代碼段重定位表的，TEXTREL表示代碼段重定位表地址2. 非PIC 本條指令有任何輸出，則hook.so就不是PIC */

地址無關代碼技術除了可以用在共享對象上面，它也可以用于可執行文件，一個以地址無關方式編譯的可執行文件被稱作地址無關可執行文件(PIE Position-Independent Executable)，與GCC的"-fPIC"類似，產生PIE的參數為"-fPIE"

0x3: PIC

ELF格式的共享庫使用"PIC技術"使代碼和數據的引用與地址無關，程序可以被加載到地址空間的任意位置。PIC在代碼中的跳轉和分支指令不使用絕對地址。PIC在ELF可執行映像的數據段中建立一個存放所有全局變量指針的全局偏移量表GOT

0X4:?全局偏移表(GOT)

1. 對于模塊外部引用的全局變量和全局函數，用GOT表的表項內容作為地址來間接尋址 2. 對于本模塊內的靜態變量和靜態函數，用GOT表的首地址作為一個基準，用相對于該基準的偏移量來引用，因為不論程序被加載到何種地址空間，模塊內的靜態變量和靜態函數與GOT的距離是固定的，并且在鏈接階段就可知曉其距離的大小

這樣，PIC使用GOT來引用變量和函數的絕對地址，把位置獨立的引用重定向到真實的絕對位置，對于PIC代碼，代碼段內不存在重定位項，實際的重定位項只是在數據段的GOT表內。共享目標文件中的重定位類型有

1. R_386_RELATIVE 2. R_386_GLOB_DAT 3. R_386_JMP_SLOT

用于在動態鏈接器加載映射共享庫或者模塊運行的時候對指針類型的靜態數據、全局變量符號地址和全局函數符號地址進行重定位

0x5:?過程鏈接表(PLT)

過程鏈接表(PLT)用于把位置獨立的函數調用重定向到絕對位置。通過PLT動態鏈接的程序支持惰性綁定模式。每個動態鏈接的程序和共享庫都有一個PLT，PLT表的每一項都是一小段代碼，對應于本運行模塊要引用的一個全局函數。程序對某個函數的訪問都被調整為對PLT入口的訪問，每個PLT入口項對應一個GOT項，執行函數實際上就是跳轉到相應GOT項存儲的地址，該GOT項初始值為PLTn項中的push指令地址(即jmp的下一條指令，所以第1次跳轉沒有任何作用)，待符號解析完成后存放符號的真正地址。動態鏈接器在裝載映射共享庫時在GOT里設置2個特殊值

1. GOT+4(即 GOT[1]): 設置動態庫映射信息數據結構link_map地址 操作系統運行程序時，首先將解釋器程序即動態鏈接器ld.so映射到一個合適的地址，然后啟動 ld.so。ld.so 先完成自己的初始化工作，再從可執行文件的動態庫依賴表中指定的路徑名查找所需要的庫，將其加載映射到內存。Linux用一個全局的庫映射信息結構struct link_map鏈表來管理和控制所有動態庫的加載，動態庫的加載過程實際上是映射庫文件到內存中，并填充庫映射信息結構添加到鏈表中的過程。結構 struct link_map描述共享目標文件的加載映射信息，是動態鏈接器在運行時內部使用的一個結構，通過它保持對已裝載的庫和庫中符號的跟蹤 link_map使用雙向鏈接中間件"l_next"和"l_prev"鏈接進程中所有加載的共享庫。當動態鏈接器需要去查找符號的時候，可以向前或向后遍歷這個鏈表，通過訪問鏈表上的每一個庫去搜索需要查找的符號 //Link_map鏈表的入口由每個可執行映像的全局偏移表的第2個入口(GOT[1])指向，查找符號時先從 GOT[1]讀取 link_map 結點地址，然后沿著link-map 結點進行搜索 2. GOT+8(即 GOT[2]): 設置動態鏈接器符號解析函數的地址_dl_runtime_resolve PLT的第1個入口PLT0是一段訪問動態鏈接器的特殊代碼。程序對PLT入口的第1次訪問都轉到了PLT0，最后跳入GOT[2]存儲的地址執行符號解析函數。待完成符號解析后，將符號的實際地址存入相應的GOT項，這樣以后調用函數時可直接跳到實際的函數地址，不必再執行符號解析函數

動態庫的加載映射過程主要分3步

1. 動態鏈接器調用__mmap函數對動態庫的所有PT_LOAD可加載段進行整體映射 /* l_map_start=(ElfW(Addr))__mmap ((void *)0, maplength, prot, MAP_COPY | MAP_FILE, fd, mapoff); */ 返回值 l_map_start 是實際映射的虛擬地址，和段結構成員，p_vaddr指定的虛擬地址不一定相同，這對于位置無關代碼不會產生影響。但是對于數據段和link_map結構中其它相關的位置描述信息還要進行修正 2. 共享文件映射完畢，動態鏈接器處理共享庫的PT_DYNAMIC動態段，將各項動態鏈接信息主要是哈希表、符號表、字符串表、重定位表、PLT 重定位項表等地址填寫到link_map的l_info數組結構中。l_info是link_map最重要的字段之一，幾乎所有與動態鏈接管理相關的內容都與l_info數組有關。動態鏈接器還要加載處理當前共享庫的所有依賴庫3. 由于實際的映射地址和指定的虛擬地址有可能不同，因此還要對動態庫及其依賴庫進行重定位。設置動態庫的第1個和第2個GOT 表項 /* Elf32_Addr *got = (Elf32_Addr *) lmap->l_info[DT_PLTGOT].d_un.d_ptr; got[1]=lmap; got[2]=&_dl_runtime_resolve; */ 對動態庫的所有重定位項進行重定位，在重定位項指定的偏移地址處加上修正值l_addr。動態項DT_REL給出了重定位表的地址，DT_RELSZ給出重定位表項的數目，映射完畢后，動態鏈接器調用共享庫(包括所有相關的依賴庫)自備的初始化函數進行初始化

Relevant Link:

http://zhiwei.li/text/2009/04/elf%E7%9A%84got%E5%92%8Cplt%E4%BB%A5%E5%8F%8Apic/#comment-4235 http://www.programlife.net/linux-got-plt.html

?

3. 延遲版定(PLT Procedure Linkage Table)

我們知道，動態鏈接比靜態鏈接慢的主要原因有如下幾個

1. 動態鏈接下對于全局和靜態的數據訪問都要進行復雜的的GOT定位，然后間接尋址，對于模塊間的調用也要先定位GOT，然后再進行間接跳轉 2. 動態鏈接的鏈接工作是在運行時完成的，動態鏈接器會尋找并裝載所需要的共享對象，然后進行符號查找地址重定位工作等

0x1: 延遲綁定的實現

在動態鏈接下，程序模塊間包含了大量的函數引用，所以在程序開始執行前，動態鏈接器會耗費大量時間用于解決模塊間的函數引用的符號查找以及重定位。但是需要明白的是，在一個程序運行過程中，可能很多函數在程序執行完時都不會被用到，例如一些錯誤處理函數或者是一些很少運行到的代碼邏輯流支，如果一開始就把所有函數都鏈接好實際上是一種浪費，所以ELF采用了一種延遲綁定(Lazy Binding)技術，即當函數第一次被用到時才進行綁定(符號查找、重定位等)，如果這個函數沒有被用到則不進行綁定。

采用了延遲綁定技術后，程序開始運行時，模塊間的函數調用全都沒有進行綁定，而是需要用到時才由動態鏈接器來負責綁定

ELF使用PLT(Procedure Linkage Table)的方法來實現，在Glibc中，實現延遲綁定功能的函數名叫"_dl_runtime_resolve()"

在開始學習PLT技術之前，我們來總結一下ELF中這種技術的核心思想

不管是模塊間的指令調用、還是跨模塊的全局靜態變量的引用，ELF使用了GOT間接跳轉來實現，本質上是使用了"中間層技術"來屏蔽可能存在的外部模塊引入的不確定性，中間層技術是實現兼容的一種很好的思考方式

PLT為了實現延遲綁定，在GOT的基礎之上又增加了一層間接跳轉，調用函數并不直接通過GOT跳轉，而是通過一個叫做PLT項的結構來進行跳轉。每個外部函數在PLT中有一個相應的項

?

4. 動態鏈接相關結構

在動態鏈接情況下，可執行文件的裝載與靜態鏈接的情況基本一樣

1. 操作系統讀取可執行文件的頭部，檢查文件的合法性 2. 從頭部中的"Program Header"中讀取每個"Segment"的虛擬地址、文件地址和屬性，并將它們映射到進程虛擬空間的相對位置 3. 在靜態鏈接情況下，這個時候操作系統就可以把控制權交給可執行文件的入口地址，然后程序開始執行

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

在Linux中，動態鏈接器ld.so實際上也是一個共享對象

1. 操作系統同樣通過映射的方式將它加載到進程的地址空間中 2. 操作系統在加載完動態鏈接器之后，就將控制權交給動態鏈接器的入口地址(與可執行文件一樣，共享對象也有入口地址) 3. 當動態鏈接器得到控制權之后，它開始執行一系列自身的初始化操作，然后根據當前的環境參數，開始對可執行文件進行動態鏈接工作 4. 當所有動態鏈接工作完成之后，動態鏈接器會將控制權轉交到可執行文件的入口地址，程序開始正式執行

0x1: .interp段

值得注意的是，動態鏈接器的位置既不是系統配置決定、也不是由環境參數決定，而是由ELF文件自身決定。在動態鏈接的ELF可執行文件中，有一個專門的段叫作 ".interp段"(interpreter(解釋器)段)

objdump -s main

".interp"里保存的就是一個字符串，表明可執行文件所需要的動態鏈接器的路徑，在Linux中，操作系統在對可執行文件進行加載的時候，會去尋找裝載該可執行文件所需要的相應的動態鏈接器，即".interp"段指定的路徑的共享對象

動態鏈接器在Linux下是Glibc的一部分，也是屬于系統庫級別的，它的版本號往往跟系統中的Glibc庫版本號一致，當系統中的Glibc庫更新或者安裝其他版本的時候，/lib64/ld-linux.so.2這個軟鏈接就是指向到新的動態鏈接器，而可執行文件本身不需要修改".interp"段中的動態鏈接器的路徑來適應系統的升級，這又是利用中間層思想帶來的兼容性的一個例子

0x2: .dynamic段?

動態鏈接器ELF中最重要的結構應該是".dynamic"段，這個段里面保存了動態鏈接器所需要的基本信息，例如依賴哪些共享對象、動態鏈接符號表的位置動態鏈接重定位表的位置、共享對象初始化代碼的地址等

linux-2.6.32.63\include\linux\elf.h

typedef struct dynamic {Elf32_Sword d_tag;union{Elf32_Sword d_val;Elf32_Addr d_ptr;} d_un; } Elf32_Dyn;typedef struct {/* entry tag value : 類型值#define DT_NULL 0#define DT_NEEDED 1#define DT_PLTRELSZ 2#define DT_PLTGOT 3#define DT_HASH 4 : 動態鏈接哈希表地址，d_ptr表示".hash"的地址#define DT_STRTAB 5 : 動態鏈接字符串表的地址，d_ptr表示".dynstr"的地址#define DT_SYMTAB 6 : 動態鏈接符號表的地址，d_ptr表示".dynsym"的地址#define DT_RELA 7 : 動態鏈接重定位表地址#define DT_RELASZ 8#define DT_RELAENT 9#define DT_STRSZ 10 : 動態鏈接字符串表大小，d_val表示大小 #define DT_SYMENT 11#define DT_INIT 12 : 初始化代碼地址#define DT_FINI 13 : 結束代碼地址#define DT_SONAME 14 : 本共享對象的"SO-NAME"#define DT_RPATH 15 : 動態鏈接共享對象搜索路徑#define DT_SYMBOLIC 16#define DT_REL 17#define DT_RELSZ 18#define DT_RELENT 19 : 動態重讀位表入口數量#define DT_PLTREL 20#define DT_DEBUG 21#define DT_TEXTREL 22#define DT_JMPREL 23#define DT_ENCODING 32#define OLD_DT_LOOS 0x60000000#define DT_LOOS 0x6000000d#define DT_HIOS 0x6ffff000#define DT_VALRNGLO 0x6ffffd00#define DT_VALRNGHI 0x6ffffdff#define DT_ADDRRNGLO 0x6ffffe00#define DT_ADDRRNGHI 0x6ffffeff#define DT_VERSYM 0x6ffffff0#define DT_RELACOUNT 0x6ffffff9#define DT_RELCOUNT 0x6ffffffa#define DT_FLAGS_1 0x6ffffffb#define DT_VERDEF 0x6ffffffc#define DT_VERDEFNUM 0x6ffffffd#define DT_VERNEED 0x6ffffffe#define DT_VERNEEDNUM 0x6fffffff#define OLD_DT_HIOS 0x6fffffff#define DT_LOPROC 0x70000000#define DT_HIPROC 0x7fffffff*/Elf64_Sxword d_tag; union {Elf64_Xword d_val;Elf64_Addr d_ptr;} d_un; } Elf64_Dyn;

從作用上來說，".dynamic"段里保存的信息類似于ELF文件頭，使用readelf -d hook.so可以查看".dynamic"段的內容

Linux還提供了一個指令來查看一個程序主模塊、或者一個共享庫依賴于哪些共享庫: ldd programe

0x3: 動態符號表?

為了完成動態鏈接，最關鍵的是所依賴的符號和相關文件的信息。為了表示動態鏈接這些模塊之間的符號導入導出關系，ELF專門有一個叫作動態符號表(dynamic symbol table)的段，這個段的段名通常為".dynsym"(dynamic symbol)。與".symtab"類似，動態符號表也需要一些輔助的表，比如用于保存符號名的字符串表，即動態符號字符串表".dynstr"(dynamic string table)，由于在動態鏈接下，我們需要在程序運行時查中啊符號，為了加快符號的查找過程，往往還有輔助的符號哈希表".hash"

0x4: 動態鏈接重定位表

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

1. ".rel.dyn" 對數據引用的修正，它所修正的位置位于".got"以及數據段2. ".rel.plt" 對函數引用的修正，它所修正的位置位于".got.plt"

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

進程初始化的時候，堆棧里保存了關于進程執行環境和命令行參數等信息，除此之外，堆棧里還保存了動態鏈接器所需要的一些輔助信息數組(auxiliary vevtor)

linux-2.6.32.63\include\linux\elf.h

typedef struct {/* Entry type #define AT_NULL 0 : 表示輔助信息數組結束#define AT_IGNORE 1 #define AT_EXECFD 2 : 表示可執行文件的文件句柄#define AT_PHDR 3 : 可執行文件中"程序頭表(program header)"在進程中的地址#define AT_PHENT 4 : 可執行文件中程序頭表每一個入口(entry)的大小#define AT_PHNUM 5 : 可執行文件頭中程序頭表中入口(entry)的數量#define AT_PAGESZ 6 #define AT_BASE 7 : 表示動態鏈接器本身的裝載地址#define AT_FLAGS 8 #define AT_ENTRY 9 : 可執行文件入口地址，即啟動地址#define AT_NOTELF 10 #define AT_UID 11 #define AT_EUID 12 #define AT_GID 13 #define AT_EGID 14 #define AT_CLKTCK 17 */u64 a_type; union{u64 a_val; /* Integer value */} a_un; } Elf64_auxv_t;

事實上，輔助信息位于環境變量指針的后面

#include <stdio.h> #include <elf.h>int main(int argc, char* argv[]) {int* p = (int*)argv;int i;Elf32_auxv_t* aux;printf("Argument count: %d\n", *(p - 1));for(i = 0; i < *(p - 1); i++){printf("Argument %d: %s\n", i, *(p + 1));}p += i;p++;//skip 0 printf("Environment: \n");while(*p){printf("%s\n", *p);p++;}p++;//skip 0 printf("Auxiliary Vectors: \n");aux = (Elf32_auxv_t*)p;while(aux->a_type != AT_NULL){printf("Type: %02d Value: %x\n", aux->a_type, aux->a_un.a_val);aux++;}return 0; }

?

5. 動態鏈接的步驟和實現

動態鏈接基本上分為3步

1. 啟動動態鏈接器本身(自舉) 2. 裝載所有需要的共享對象 3. 重定位、初始化

0x1: 動態鏈接器自舉

我們知道，對于Linux程序中的普通共享對象(DSO)文件來說

1. 普通DSO的重定位工作由動態鏈接器來完成 2. 普通DSO依賴的其他共享對象由動態鏈接器負責鏈接和裝載

而對于動態鏈接器對應的DSO文件來說

1. 動態鏈接器本身不可以依賴于其他任何共享對象 編寫動態鏈接器時保證不使用任何系統庫、運行庫2. 動態鏈接器本身所需要的全局和靜態變量的重定位工作由它本身完成

動態鏈接器必須在啟動時有一段很精巧的代碼可以完成這項艱巨的工作同時又不能用到全局和靜態變量。這種具有一定限制條件的啟動代碼往往被稱為"自舉(Boosttrap)"

1. 動態鏈接器入口地址就是自舉代碼的入口，當操作系統將進程控制權交給動態鏈接器時，動態鏈接器的自舉代碼即開始執行 2. 自舉代碼會找到自己的GOT。而GOT的第一個入口保存的即是".dynamic"段的偏移地址，由此獲得了動態鏈接器本身的".dynamic"段 3. 通過".dynamic"段中的信息，自舉代碼便可以獲得動態鏈接器本身的重定位表和符號表等，從而得到動態鏈接器本身的重定位入口，先將它們全部重定位 4. 從這一步開始動態鏈接器代碼中才可以開始使用自己的全局變量和靜態變量

0x2: 裝載共享對象

完成基本自舉后，動態鏈接器將可執行文件和鏈接器自身的符號表都合并到一個符號表中，我們稱之為"全局符號表(Global Symbol Table)"。然后鏈接器開始尋找可執行文件所依賴的共享對象，在".dynamic"段中，有一種類型的入口是DT_NEEDED，它標識了該可執行文件(或共享對象)所依賴的共享對象。由此

1. 鏈接器可以列出可執行文件所需要的所有共享對象，并將這些共享對象的名字放入到一個裝載集合中 2. 然后鏈接器開始從集合里取一個所需要的共享對象的名字，找到相應的文件后打開該文件，讀取相應的ELF文件頭和".dynamic"段，然后將它相應的代碼段和數據段映射到進程空間中 3. 如果這個ELF共享對象還依賴于其他共享對象，那么將所依賴的共享對象的名字放到裝載集合中，如果循環知道所有依賴的共享對象都被裝載進來為止 4. 鏈接器對共享對象的遍歷過程本質上是一個圖的遍歷過程，鏈接器可能會使用深度優先、或者廣度優先的順序來進行 5. 當一個新的共享對象被裝載進來的時候，它的符號表會被合并到全局符號表中，所以當所有的共享對象都被裝載進來的時候，全局符號表里面將包含進程中所有動態鏈接鎖需要的符號

符號優先級

在動態鏈接器按照各個模塊之間的依賴關系，對它們進行裝載并且將它們的符號"合并"到全局符號表時，會發生兩個不同的模塊定義了一個同名的符號
編寫示例代碼模擬這個場景

1. 定義一個簡單的輸出demo函數(同名) /* a1.c */ #include <stdio.h>void a() {printf("a1.c\n"); }/* a2.c */ #include <stdio.h>void a() {printf("a2.c\n"); } 可以看到，a1.c、a2.c中都定義了名為"a"的函數2. 顯式指定依賴關系 /* 代碼中調用a() b1.c */ void a();void b1() {a(); }/* 代碼中調用a() b2.c */ void a();void b2() {a(); }3. 根據依賴關系進行編譯 //b1.so依賴a1.so gcc -fPIC -shared a1.c -o a1.so gcc -fPIC -shared b1.c a1.so -o b1.so//b2.so依賴a2.so gcc -fPIC -shared a2.c -o a2.so gcc -fPIC -shared b2.c a2.so -o b2.so4. 同時引入b1.so、b2.so，模擬同名符號沖突的情況 /* main.c */ #include <stdio.h>void b1(); void b2();int main() {b1();b2();return 0; } gcc main.c b1.so b2.so -o main -Xlinker -rpath ./ ./main

當動態鏈接器對main程序進行動態鏈接時，b1.so、b2.so、a1.so、a2.so都會被裝載到進程的地址空間中，并且它們的符號都會被"合并"到全局符號表中，當發生同名符號重合的情況時，這種現象叫做"全局符號介入(global symbol interpose)"
Linux下的動態鏈接器的處理規則是這樣的

1. 當一個符號需要被加入到全局符號表時，如果相同的符號名已經存在，則后載入的符號被忽略 2. 按照廣度優先的順序進行加載 3. 如果優先引入的函數(符號)沒有顯式地進行調用鏈獲取，并在完成自身邏輯后調用調用鏈上的下一個函數，則后引入的函數(符號)將被忽略 #define FN(ptr,type,name,args) ptr = (type (*)args)dlsym (REAL_LIBC, name)

0x3: 重定位和初始化

當完成動態鏈接器的裝載、普通共享對象的裝載之后，鏈接器開始重新遍歷可執行文件和每個共享對象的重定位表，將它們的GOT/PLT中的每個需要重定位的位置進行修正
重定位完成后就，如果某個共享對象有".init"段，那么動態鏈接器會執行".init"段中的代碼，用以實現共享對象特有的初始化過程，例如共享對象中的C++全局/靜態對象的構造就是通過"init"段來初始化

當完成了重定位和初始化后，所有的準備工作就宣告完成了，所需要的共享對象也都已經裝載并且鏈接完成了，這個時候進程的控制權就由動態鏈接器轉交給程序的入口并且開始執行

Relevant Link:

?

6. Linux動態鏈接器實現

Linux動態鏈接器本身是一個共享對象，它的路徑是"/lib/ld-linux.so.2、/lib64/ld-linux-x86-64.so.2"。共享對象本質上也是一個ELF文件，包含ELF文件頭(包括e_entry、段表等)，而動態鏈接器是個非常特殊的共享對象，它不僅是個共享對象，還是一個可執行程序，可以直接在命令行下運行

/lib64/ld-linux-x86-64.so.2

Linux的ELF動態鏈接器是glibc的一部分，它的源代碼位于glibc的源代碼的ELF目錄下

\glibc-2.18\sysdeps\i386\dl-machine.h

/* Initial entry point code for the dynamic linker.The C function `_dl_start' is the real entry point;its return value is the user program's entry point. */#define RTLD_START asm ("\n\.text\n\.align 16\n\ 0: movl (%esp), %ebx\n\ret\n\.align 16\n\ .globl _start\n\ .globl _dl_start_user\n\ _start:\n\# Note that _dl_start gets the parameter in %eax.\n\movl %esp, %eax\n\call _dl_start\n\ _dl_start_user:\n\# Save the user entry point address in %edi.\n\movl %eax, %edi\n\# Point %ebx at the GOT.\n\call 0b\n\addl $_GLOBAL_OFFSET_TABLE_, %ebx\n\# See if we were run as a command with the executable file\n\# name as an extra leading argument.\n\movl _dl_skip_args@GOTOFF(%ebx), %eax\n\# Pop the original argument count.\n\popl %edx\n\# Adjust the stack pointer to skip _dl_skip_args words.\n\leal (%esp,%eax,4), %esp\n\# Subtract _dl_skip_args from argc.\n\subl %eax, %edx\n\# Push argc back on the stack.\n\push %edx\n\# The special initializer gets called with the stack just\n\# as the application's entry point will see it; it can\n\# switch stacks if it moves these contents over.\n\ " RTLD_START_SPECIAL_INIT "\n\# Load the parameters again.\n\# (eax, edx, ecx, *--esp) = (_dl_loaded, argc, argv, envp)\n\movl _rtld_local@GOTOFF(%ebx), %eax\n\leal 8(%esp,%edx,4), %esi\n\leal 4(%esp), %ecx\n\movl %esp, %ebp\n\# Make sure _dl_init is run with 16 byte aligned stack.\n\andl $-16, %esp\n\pushl %eax\n\pushl %eax\n\pushl %ebp\n\pushl %esi\n\# Clear %ebp, so that even constructors have terminated backchain.\n\xorl %ebp, %ebp\n\# Call the function to run the initializers.\n\call _dl_init_internal@PLT\n\# Pass our finalizer function to the user in %edx, as per ELF ABI.\n\leal _dl_fini@GOTOFF(%ebx), %edx\n\# Restore %esp _start expects.\n\movl (%esp), %esp\n\# Jump to the user's entry point.\n\jmp *%edi\n\.previous\n\ ");

執行流程如下

1. _start()調用_dl_start()函數 2. _dl_start()首先對ld-x.y.z.so進行重定位，因為ld-x.y.z.so自身是動態鏈接器，它必須自己完成重定位，即"自舉" 3. 完成自舉后就可以調用其他函數、并且訪問全局變量了 4. 調用_dl_start_final()收集一些基本的運行數值，進入_dl_sysdep_start() 5. _dl_sysdep_start()進行了一些平臺相關的處理之后就進入了_dl_main()，這是動態鏈接器的主函數

Relevant Link:

http://mirror.hust.edu.cn/gnu/glibc/

?

7. 顯式運行時鏈接

支持動態鏈接的系統大部分都支持一種更加靈活的模塊加載方式，即"顯式運行時鏈接(explicit run-time linking)(運行時加載)"。讓程序自己在運行時控制加載指定的模塊，并且可以在不需要該模塊時將其卸載

在Linux中，從文件本身的格式上來看，動態庫實際上和共享對象庫沒有區別，主要的區別是

1. 共享對象是由動態鏈接器在程序啟動之前負責裝載和鏈接的，這一系列步驟都由動態鏈接器自動完成，對于程序本身是透明的2. 動態庫的裝載是通過一些列的動態鏈接器提供的API按成的 /* #include <dlfcn.h> /lib.lindl.so.2 */

0x1: dlopen()

打開一個動態鏈接庫，將其加載到進程的地址空間，并返回動態鏈接庫的句柄，完成初始化過程

void * dlopen( const char * pathname, int mode); 1. pathname: 被加載動態庫的路徑 值得注意的是： 如果pathname傳入是0，則dlopen返回的是全局符號表的句柄，也就是說我們可以在運行時找到全局符號表里面的任何一個符號，并且可以執行它們，這類似于高級語言中的反射(relection)特性 全局符號表包括了程序的可執行文件本身、被動態鏈接器加載到進程中的所有共享模塊、運行時通過dlopen打開并且使用了RTLD_GLOBAL方式的模塊中的符號2. mode: mode是打開方式，其值有多個，不同操作系統上實現的功能有所不同，在linux下，按功能可分為三類：2.1 解析方式1) RTLD_LAZY: 在dlopen返回前，對于動態庫中的未定義的符號不執行解析(只對函數引用有效，對于變量引用總是立即解析)2) RTLD_NOW: 需要在dlopen返回前，解析出所有未定義符號，如果解析不出來，在dlopen會返回NULL，錯誤為：: undefined symbol: xxxx.......2.2 作用范圍: 可與解析方式通過"|"組合使用 1) RTLD_GLOBAL: 動態庫中定義的符號可被其后打開的其它庫解析 2) RTLD_LOCAL: 與RTLD_GLOBAL作用相反，動態庫中定義的符號不能被其后打開的其它庫重定位。如果沒有指明是RTLD_GLOBAL還是RTLD_LOCAL，則缺省為RTLD_LOCAL 2.3 作用方式1) RTLD_NODELETE: 在dlclose()期間不卸載庫，并且在以后使用dlopen()重新加載庫時不初始化庫中的靜態變量。這個flag不是POSIX-2001標準 2) RTLD_NOLOAD: 不加載庫。可用于測試庫是否已加載(dlopen()返回NULL說明未加載，否則說明已加載），也可用于改變已加載庫的flag，如：先前加載庫的flag為RTLD_LOCAL，用dlopen(RTLD_NOLOAD|RTLD_GLOBAL)后flag將變成RTLD_GLOBAL。這個flag不是POSIX-2001標準 3) RTLD_DEEPBIND: 在搜索全局符號前先搜索庫內的符號，避免同名符號的沖突。這個flag不是POSIX-2001標準

dlopen會嘗試以一定的順序去查找動態庫文件

1. 查找環境變量LD_LIBRARY_PATH指定的一些列目錄 2. 查找由/etc/ld.so.cache指定的共享庫路徑 3. /lib/、/usr/lib

0x2: dlsym()

根據動態鏈接庫操作句柄與符號，返回符號對應的地址

#include <dlfcn.h> void * dlsym(void *handle, constchar *symbol)

符號優先級

1. 全局符號的優先級 我們知道，在全局符號的引入中，不管是動態鏈接器在程序啟動時引入依賴的動態共享庫、LD_LIBRARY_PATH指定引入的動態共享庫、還是程序在運行時中調用dlopen引入動態共享庫。當發生多個同名符號沖突時，都遵循"先來后到"的原則，即先裝入的符號優先，這種優先級方式稱為"裝載序列(Load Ordering)"2. dlsym()動態符號的優先級 dlsym()對符號的查找優先級分為兩種1) 裝載序列:在全局符號表中進行遵循裝載序列的搜索: 在dlopen的時候pathname傳入02) 依賴序列:從目標共享模塊開始進行遵循依賴序列的搜索: 在dlopen的時候pathname傳入目標模塊路徑，在dlsym的時候傳入dlopen返回的句柄指針所謂依賴序列就是以被dlopen打開的那個共享對象為根節點，對它所有依賴的共享對象進行廣度優先遍歷，找到了就返回，如果沒找到就繼續找，直到找到符號為止

我們可以使用下面的代碼來幫助我們理解這個原理

/* hook.c */ #include <stdio.h> #include <string.h> #include <dlfcn.h> int strcmp(const char *s1, const char *s2) { //這個hook函數只是簡單地打印一句話printf("oops!!! hack function invoked\n"); } gcc -fPIC -shared -o hook.so hook.c -ldl cp hook.so /lib64//* main.c */ #include <stdio.h> #include <dlfcn.h>int main(int argc, char **argv) {void *handle1, *handle2;int (*cosine1)(const char *, const char *);int (*cosine2)(const char *, const char *);char *error;//返回hook.so的模塊句柄handle1 = dlopen ("hook.so", RTLD_LAZY);//返回全局符號表handle2 = dlopen (0, RTLD_LAZY);if (!handle1 | !handle2) {fprintf (stderr, "%s\n", dlerror());return 0;}//從剛才打開的句柄中搜索符號cosine1 = dlsym(handle1, "strcmp");//從全局符號表中搜索符號cosine2 = dlsym(handle2, "strcmp");if ((error = dlerror()) != NULL) {fprintf (stderr, "%s\n", error);return 0;}//采用依賴序列(dependency ordering)優先級進行符號搜索，優先執行動態引入的hook.so的函數printf ("%f\n", (*cosine1)("aaa", "bbb"));//采用裝載序列(load ordering)優先級啊進行符號搜索，動態引入的hook.so被忽略printf ("%f\n", (*cosine2)("aaa", "bbb"));dlclose(handle1);dlclose(handle2);return 0; } gcc -rdynamic -o main main.c -ldl

0x3: dlclose()

dlclose()的作用和dlopen()相反，它的作用是將一個已加載的模塊卸載，系統會維持一個加載引用的計數器

1. dlopen 計數器加12. dlclose 計數器減1 只有當計數器減到0時，模塊才被真正地卸載掉，卸載的過程正好相反，先執行".finit"段代碼，然后將相應的符號從符號表中去除，取消進程空間跟模塊的映射關系，然后關閉模塊文件

?

8. 共享庫系統路徑 && 默認加載順序

目前大多數包括Linux在內的開源操作系統都遵守FHS(File Hierarchy Standard 文件系統層次結構標準)標準，它包括了以下目錄結構

1. / : 第一層次結構的根，整個文件系統層次結構的根目錄 2. /bin/ : 需要在單用戶模式可用的必要命令(可執行文件)，例如 1) cat2) ls3) cp 3. /boot/ : 引導程序文件，例如 1) kernel2) initrd 4. /dev/ : 必要設備，例如 1) /dev/null 5. /etc/ : 系統范圍內的配置文件 6. /home/ : 用戶的工作目錄，包含保存的文件、個人設置等 7. /lib/ : /bin/、/sbin/中二進制文件必要的庫文件 8. /media/ : 可移除媒體(如CD-ROM)的掛載點(在FHS-2.3中出現) 9. /mnt/ : 臨時掛載的文件系統 10. /opt/ : 可選應用軟件包 11. /proc/ : 虛擬文件系統，將內核與進程狀態歸檔為文本文件，例如 1) uptime2) network 在Linux中，對應Procfs格式掛載 12. /root/ : 超級用戶的工作目錄 13. /sbin/ : 必要的系統二進制文件，例如1) init2) ip3) mount 14. /srv/ : 站點的具體數據，由系統提供 15. /tmp/ : 臨時文件(參見 /var/tmp)，在系統重啟時目錄中文件不會被保留 16. /usr/ : 用于存儲用戶數據，包含絕大多數的(多)用戶工具和應用程序 17. /var/

遵循這種約定標準，它有助于促進各個開源操作系統之間兼容性，按照FHS規定，一個系統中主要有3個存放共享庫的位置

1. /lib: 存放系統最關鍵和基礎的共享庫，例如1) 動態鏈接器2) C語言運行庫3) 數學庫 這些庫主要是那些/bin、/sbin下的程序以及系統啟動時所要用到的庫2. /usr/lib: 存放一些非系統運行時所需要的關鍵性的共享庫，只要是一些開發時用到的共享庫3. /usr/local/lib: 存放一些跟操作系統本身并不十分相關的庫，主要是一些第三方的應用程序的庫

0x1: 共享庫的查找過程

我們知道，包括Linux系統在內的很多開源系統都是基于Glibc的，動態鏈接的ELF可執行文件在啟動時同時會啟動動態鏈接器(/lib/ld-linux.so.X)，程序所依賴的共享對象全部由動態鏈接器負責裝載和初始化，所以這里所謂的共享庫的查找過程，本質上就是動態鏈接器(/lib/ld-linux.so.X)對共享庫路徑的搜索過程，搜索過程如下

1. 根據ELF文件中的配置信息 任何一個動態鏈接的模塊所依賴的模塊路徑保存在".dynamic"段中，由DT_NEED類型的項表示，動態鏈接器會按照這個路徑去查找DT_RPATH所指定的路徑，編譯目標代碼時，可以對gcc加入鏈接參數"-Wl,-rpath"指定動態庫搜索路徑 2. DT_NEED段中保存的是絕對路徑，則動態鏈接器直接按照這個路徑進行直接加載3. 根據LD_PRELOAD中指定的路徑加載共享庫、目標文件/* 4. /etc/ld.so.cache 到了這一步，如果動態鏈接器(/lib/ld-linux.so.X)沒有得到可以直接打開的絕對路徑，則需要開始根據相對路徑進行共享庫的搜索 Linux為了加速這個搜索過程，在系統中建立了一個ldconfig程序，這個程序負責1) 將共享庫下的各個共享庫維護一個SO-NAME(一一對應的符號鏈接)，這樣每個共享庫的SO-NAME就能夠指向正確的共享庫文件2) 將全部SO-NAME收集起來，集中放到/etc/ld.so.cache文件里面，并建立一個SO-NAME的緩存 當動態鏈接器要查找共享庫時，它可以直接從/etc/ld.so.cache里面查找所以，如果我們在系統指定的共享庫目錄下添加、刪除或更新任何一個共享庫，或者我們更改了/etc/ld.so.conf、/etc/ld.preload的配置，都應該運行一次ldconfig這個程序，以便更新SO-NAME和/etc/ld.so.cache 很多軟件包的安裝程序在結束共享庫安裝以后都會調用ldconfig */5. 根據/etc/ld.so.preload中的配置進行搜索 這個配置文件中保存了需要搜索的共享庫路徑，Linux動態共享庫加載器根據順序進行逐行廣度搜索6. 根據環境變量LD_LIBRARY_PATH指定的動態庫搜索路徑 7. DT_NEED段中保存的是相對路徑，動態鏈接器會在按照一個約定的順序進行庫文件查找1) /lib2) /usr/lib3) 由/etc/ld.so.conf中配置指定的搜索路徑

0x2: 環境變量: LD_LIBRARY_PATH

在Linux系統中，LD_LIBRARY_PATH是一個由若干個路徑組成的環境變量，每個路徑之間由冒號隔開，默認情況下，LD_LIBRARY_PATH為空，設置方法如下

1. LD_LIBRARY_PATH=/home/user/ /bin/ls 2. /lib64/ld-linux.so.2 -library-path /home/user /bin/ls

LD_LIBRARY_PATH對于共享庫的開發和測試十分方便，但是不應該被濫用，隨意修改LD_LIBRARY_PATH并且將其導出至全局范圍，將可能引起其他應用程序運行出現問題。同時，LD_LIBRARY_PATH也會影響GCC編譯時查找庫的路徑，里里面包含的目錄相當于鏈接時GCC的"-L"參數

0x3: 環境變量: LD_PRELOAD

借助這個環境變量，我們可以指定預先裝載的一些共享庫、目標文件。它的優先級是所有相對路徑搜索中最高的，無論程序是否需要它們，LD_PRELOAD指定的共享庫或目標文件都會被加載
由于全局符號介入這個機制的存在，LD_PRELOAD里面指定的共享庫或目標文件的全局符號就會覆蓋后面加載的同名全局符號，這使得我們可以很方便地實現改寫標準C庫中的某幾個函數而不影響其他函數，對于程序測試和調試非常有用

0x4: 環境變量: LD_DEBUG

這個變量可以打開動態鏈接器的調試功能，當我們設置這個變量時，動態鏈接器會在運行時打印出各種有用的調試信息，對于開發和調試共享庫有很大幫助

LD_DEBUG=files ./killme

18745: 18745: file=/usr/local/$LIB/aegis_monitor.so [0]; needed by ./killme [0]18745: file=/usr/local/$LIB/aegis_monitor.so [0]; generating link map18745: dynamic: 0x00007f981c8d9cd0 base: 0x00007f981c6d8000 size: 0x0000000000201f7818745: entry: 0x00007f981c6d8be0 phdr: 0x00007f981c6d8040 phnum: 518745: 18745: 18745: file=libc.so.6 [0]; needed by ./killme [0]18745: file=libc.so.6 [0]; generating link map18745: dynamic: 0x00007f981c6c3b40 base: 0x00007f981c336000 size: 0x000000000039390818745: entry: 0x00007f981c354e70 phdr: 0x00007f981c336040 phnum: 1018745: 18745: 18745: file=libdl.so.2 [0]; needed by /usr/local/lib64/aegis_monitor.so [0]18745: file=libdl.so.2 [0]; generating link map18745: dynamic: 0x00007f981c334da0 base: 0x00007f981c132000 size: 0x000000000020310018745: entry: 0x00007f981c132de0 phdr: 0x00007f981c132040 phnum: 918745: 18745: 18745: calling init: /lib64/libc.so.618745: 18745: 18745: calling init: /lib64/libdl.so.218745: 18745: 18745: calling init: /usr/local/lib64/aegis_monitor.so18745: 18745: 18745: initialize program: ./killme18745: 18745: 18745: transferring control: ./killme18745: 18745: 18745: calling fini: ./killme [0]18745: 18745: 18745: calling fini: /usr/local/lib64/aegis_monitor.so [0]18745: 18745: 18745: calling fini: /lib64/libdl.so.2 [0]18745: 18745: 18745: calling fini: /lib64/libc.so.6 [0]18745:

動態鏈接器打印出了整個裝載過程，顯示程序依賴于哪個共享庫并且按照什么步驟裝載和初始化、共享庫裝載時的地址等
LD_DEBUG還可以設置成其他值

1. bindings: 顯示動態鏈接的符號綁定過程 2. libs: 顯示共享庫的查找過程 3. versions: 顯示符號的版本依賴關系 4. reloc: 顯示重定位過程 5. symbols: 顯示符號表查找過程 6. statistics: 顯示動態鏈接過程中的各種統計信息 7. all: 顯示以上所有信息 8. help: 顯示上面的各種可選值的幫助信息

Relevant Link:

http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

總結

以上是生活随笔為你收集整理的Linux Dynamic Shared Library LD Linker的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。