接著上一篇部落格。前面的工作都是在核心完成的，接下來會回到使用者空間。

第一步，直譯器（也可以叫動態連結器）首先檢查可執行程式所依賴的共享庫，並在需要的時候對其進行載入。

ELF 檔案有一個特別的節區： .dynamic，它存放了和動態連結相關的很多資訊，例如動態連結器通過它找到該檔案使用的動態連結庫。不過，該資訊並未包含動態連結庫的絕對路徑，但直譯器通過 LD_LIBRARY_PATH 引數可以找到（它類似 Shell 直譯器中用於查詢可執行檔案的 PATH 環境變數，也是通過冒號分開指定了各個存放庫函式的路徑）該變數實際上也可以通過/etc/ld.so.conf 檔案來指定，一行對應一個路徑名。為了提高查詢和載入動態連結庫的效率，系統啟動後會通過 ldconfig 工具建立一個庫的快取 /etc/ld.so.cache 。如果使用者通過 /etc/ld.so.conf 加入了新的庫搜尋路徑或者是把新庫加到某個原有的庫目錄下，最好是執行一下 ldconfig 以便重新整理快取。

找到動態連結庫後，就可以將其載入到記憶體中。

第二步，直譯器對程式的外部引用進行重定位，並告訴程式其引用的外部變數/函式的地址，此地址位於共享庫被載入在記憶體的區間內。動態連結還有一個延遲定位的特性，即只有在“真正”需要引用符號時才重定位，這對提高程式執行效率有極大幫助。（如果設定了 LD_BIND_NOW 環境變數，這個動作就會直接進行）

下面具體說明符號重定位的過程。

首先了解幾個概念。符號，也就是可執行程式程式碼段中的變數名、函式名等。重定位是將符號引用與符號定義進行連結的過程，對符號的引用本質是對其在記憶體中具體地址的引用，所以本質上來說，符號重定位要解決的是當前編譯單元如何訪問「外部」符號這個問題。動態連結是在程式執行時對符號進行重定位，也叫執行時重定位（而靜態連結則是在編譯時進行，也叫連結時重定位）

現代作業系統中，二進位制映像的程式碼段不允許被修改，而資料段能被修改。

編寫如下程式碼

通過gcc編譯成.o檔案後，再通過objdump-d命令得到檔案的彙編指令，如下所示

call指令的運算元是fc ff ff ff，翻譯成16進位制數是0xfffffffc，看成有符號是-4。這裡應該存放printf函式的地址，但由於編譯階段無法知道printf函式的地址，所以預先放一個-4在這裡。所以程式為了正確執行，需要在連結時對其地址進行修正。這裡的原理對靜態連結和動態連結來說都是一樣的。

但對於動態連結來說，有兩個不同的地方：

（1）因為不允許對可執行檔案的程式碼段進行載入時符號重定位，因此如果可執行檔案引用了動態庫中的資料符號，則在該可執行檔案內對符號的重定位必須在連結階段完成，為做到這一點，連結器在構建可執行檔案的時候，會在當前可執行檔案的資料段裡分配出相應的空間來作為該符號真正的記憶體地址，等到執行時載入動態庫後，再在動態庫中對該符號的引用進行重定位：把對該符號的引用指向可執行檔案資料段裡相應的區域。

（2）ELF 檔案對呼叫動態庫中的函式採用了所謂的"延遲繫結"(lazy binding)策略, 只有當該函式在其第一次被呼叫發生時才最終被確認其真正的地址，因此我們不需要在呼叫動態庫函式的地方直接填上假的地址，而是使用了一些跳轉地址作為替換，這樣一來連修改動態庫和可執行程式中的相應程式碼都不需要進行了，當然延遲繫結的目的不是為了這個，具體先不細說。

可執行程式對符號的訪問又分為模組內和模組間的訪問，這裡只介紹模組間的訪問，也就是訪問動態連結庫中的符號。

通過gcc生成test可執行檔案，然後同樣用objdump-d得到可執行檔案的彙編指令，如下所示

可以看到這裡的call指令指向了80482e0地址處，也即是PLT。

PLT就是程式連結表（Procedure Link Table），屬於程式碼段。用於把位置獨立的函式呼叫重定向到絕對位置。每個動態連結的程式和共享庫都有一個PLT，PLT表的每一項都是一小段程式碼，從對應的GOT表項中讀取目標函式地址。程式對某個函式的第一次訪問都被調整為對 PLT入口也就是PLT0的訪問，也就是說所有的PLT首次執行時，最後都會跳轉到第一個PLT中執行。PLT0是一段訪問動態連結器的特殊程式碼，是動態連結做符號解析和重定位的公共入口。這樣做的好處是不用每個PLT表都有重複的一份指令，可以減少PLT指令條數。

PLT表結構如下圖所示

可以看到，PLT會先執行jmp指令跳轉到某一個地址，而這個地址就對應的GOT表項。

GOT就是全域性偏移表(Global Offset Table)，屬於資料段。為了能使得程式碼段裡對資料及函式的引用與具體地址無關，只能再作一層跳轉，ELF 的做法是在動態庫的資料段中加一個表項，也就是GOT 。GOT表格中放的是資料全域性符號的地址，該表項在動態庫被載入後由動態載入器進行初始化，動態庫內所有對資料全域性符號的訪問都到該表中來取出相應的地址，即可做到與具體地址了，而該表作為動態庫的一部分，訪問起來與訪問模組內的資料是一樣的。

GOT表結構如下圖所示

GOT[0]對應本ELF動態段(.dynamic段）的裝載地址，GOT[1]對應本ELF的link_map資料結構描述符地址，GOT[2]：對應_dl_runtime_resolve動態連結器函式的地址。3個特殊項後面依次是每個動態庫函式的GOT表項

上面講到PLT通過jmp指令跳轉到GOT表中去取函式的真實地址，而符號所對應的表項開始是沒有這個地址的，而是存放了該PLT表項jmp指令的下一條指令地址，也就是push指令。回到了PLT表項對應的指令中繼續執行，最後一條jmp指令跳轉到了PLT0中執行。

PLT0對應的指令執行了下列過程：首先pushl把 804a004(GOT[1])這塊記憶體裡的qword入棧,這個qword是link_map的地址,根據這個地址可以找到動態庫的符號表。然後jmp跳轉到GOT表中的第三項，找到動態連結器的_dl_runtime_resolve函式地址，開始執行該函式。回想前面講到的核心中載入目標映像的過程，可執行檔案在Linux核心通過exeve裝載完成之後，不直接執行，而是先跳到動態連結器（ld-linux-XXX）執行。在ld-linux-XXX裡將link_map地址、_dl_runtime_resolve地址寫到GOT表項內。所以在此時，該GOT表項的不為空。（前面三個GOT表項都是這樣被寫入的）然後當程式載入其它動態庫的時候,會把動態庫的符號資訊插入link_map

_dl_runtime_resolve函式得到動態連結庫中函式的地址後（該過程以後再分析），寫回到對應的GOT表項中。

這就是函式第一次被呼叫時執行的過程。以後每次被呼叫直接從GOT表中取到函式地址就可以了。

總的來說，動態重定位的過程可以由下圖表示