前面已經(jīng)弄清楚了.o、ELF、Section、Segment 和靜態(tài)鏈接。程序編譯鏈接完成以后還差最后一步它到底是怎么跑起來的比如我在終端輸入./main程序顯然不會(huì)憑空出現(xiàn)在內(nèi)存里。操作系統(tǒng)需要先讀取 ELF 文件建立進(jìn)程的地址空間把程序需要的內(nèi)容加載進(jìn)去。如果程序還依賴了libc.so libmystdio.so這些動(dòng)態(tài)庫(kù)也得處理。這一篇主要把這部分串起來。一、ELF還沒加載進(jìn)內(nèi)存的時(shí)候有地址嗎剛開始接觸這個(gè)問題時(shí)我會(huì)覺得程序都還在磁盤里沒有進(jìn)入內(nèi)存怎么可能已經(jīng)有地址但 ELF 文件本身已經(jīng)有自己的地址組織方式了。在現(xiàn)代計(jì)算機(jī)的平坦模式下程序中的代碼和數(shù)據(jù)會(huì)進(jìn)行統(tǒng)一編址。所以即使程序此時(shí)還在磁盤上這些代碼和數(shù)據(jù)也已經(jīng)擁有對(duì)應(yīng)的邏輯地址關(guān)系。使用objdump-Smain或者查看 ELF Headerreadelf-hmain都可以看到這些信息。二、程序從哪里開始執(zhí)行一個(gè) ELF 可執(zhí)行文件里面有一個(gè)很重要的字段Entry point address也就是程序入口地址。比如Entry point address: 0x1060程序啟動(dòng)的時(shí)候并不是直接跑到我們寫的main()而是先從入口位置開始。Linux 下通常會(huì)先進(jìn)入_start然后經(jīng)過 C 運(yùn)行時(shí)環(huán)境的初始化最后才進(jìn)入main所以程序啟動(dòng) ↓ _start ↓ 初始化 ↓ 動(dòng)態(tài)鏈接等處理 ↓ __libc_start_main ↓ main這個(gè)過程平時(shí)寫 C/C 的時(shí)候基本看不到但真正運(yùn)行的時(shí)候確實(shí)存在。三、Segment和進(jìn)程地址空間前面研究 ELF 的時(shí)候已經(jīng)知道Section 最終會(huì)根據(jù)屬性組合成 Segment。程序加載的時(shí)候真正和內(nèi)存布局關(guān)系比較密切的就是 Segment。一個(gè) Segment 會(huì)有自己的起始地址 長(zhǎng)度 權(quán)限這些信息可以拿來初始化進(jìn)程地址空間中的對(duì)應(yīng)區(qū)域?？梢源致缘乩斫獬蒃LF ↓ Program Header Table ↓ 找到各個(gè)需要加載的 Segment ↓ 建立進(jìn)程地址空間 ↓ 把對(duì)應(yīng)內(nèi)容映射進(jìn)去所以 Program Header Table 對(duì)運(yùn)行時(shí)加載非常重要。四、是不是所有Section都會(huì)加載到內(nèi)存不是。ELF 里有很多 Section 是為了鏈接、調(diào)試或者描述文件結(jié)構(gòu)準(zhǔn)備的并不是每一個(gè)都需要作為程序內(nèi)容加載到內(nèi)存。真正和加載有關(guān)的是 Program Header Table 里面的 Segment。例如readelf-lmain可以看到LOAD LOAD DYNAMIC ...其中LOAD表示這一部分后面要被加載。所以Section ↓ ELF文件內(nèi)部怎么組織 Segment ↓ 運(yùn)行時(shí)怎么加載這個(gè)區(qū)別到這里就比較好理解了。五、靜態(tài)鏈接和動(dòng)態(tài)鏈接最大的區(qū)別靜態(tài)鏈接的時(shí)候.o 靜態(tài)庫(kù)中的.o ↓ 一起鏈接 ↓ 獨(dú)立可執(zhí)行文件庫(kù)里的代碼已經(jīng)進(jìn)入最終程序。動(dòng)態(tài)鏈接則不一樣。比如ldd main.exe可能看到libc.so.6 /lib64/ld-linux-x86-64.so.2這些動(dòng)態(tài)庫(kù)并沒有在編譯鏈接時(shí)把完整代碼直接塞進(jìn)可執(zhí)行文件。程序真正啟動(dòng)以后動(dòng)態(tài)鏈接器才會(huì)去處理這些庫(kù)。所以可以把動(dòng)態(tài)鏈接理解成把一部分鏈接工作推遲到程序運(yùn)行的時(shí)候。六、動(dòng)態(tài)庫(kù)為什么不會(huì)每個(gè)進(jìn)程都復(fù)制一份假設(shè)機(jī)器上同時(shí)運(yùn)行程序A 程序B 程序C它們都需要libc.so如果每個(gè)進(jìn)程都在內(nèi)存里完整復(fù)制一份那肯定浪費(fèi)。動(dòng)態(tài)鏈接的一個(gè)重要特點(diǎn)就是多個(gè)進(jìn)程可以共享同一份動(dòng)態(tài)庫(kù)代碼。動(dòng)態(tài)庫(kù)加載到內(nèi)存以后不同進(jìn)程都可以通過自己的地址空間去訪問它從而減少內(nèi)存和磁盤空間的浪費(fèi)。七、動(dòng)態(tài)庫(kù)加載以后地址一定一樣嗎不一定。一個(gè)進(jìn)程和另一個(gè)進(jìn)程的地址空間并不相同。而且一個(gè)動(dòng)態(tài)庫(kù)每次加載到內(nèi)存的位置也可能不同。所以動(dòng)態(tài)庫(kù)不能簡(jiǎn)單地寫死我永遠(yuǎn)在 0x12345678這種絕對(duì)地址。它更適合使用相對(duì)地址。也就是動(dòng)態(tài)庫(kù)起始地址 函數(shù)在庫(kù)中的偏移量 函數(shù)真正的地址這樣動(dòng)態(tài)庫(kù)換一個(gè)位置以后只要起始地址變化內(nèi)部的偏移關(guān)系仍然有效。八、動(dòng)態(tài)庫(kù)到底怎么和當(dāng)前進(jìn)程對(duì)應(yīng)起來可以把過程想成這樣進(jìn)程 ↓ 加載動(dòng)態(tài)庫(kù) ↓ 動(dòng)態(tài)庫(kù)映射到進(jìn)程地址空間 ↓ 知道動(dòng)態(tài)庫(kù)起始地址 ↓ 知道某個(gè)函數(shù)在庫(kù)里的偏移量 ↓ 找到函數(shù)比如某個(gè)函數(shù)在動(dòng)態(tài)庫(kù)中的偏移是0x500當(dāng)前動(dòng)態(tài)庫(kù)加載到0x70000000那么函數(shù)地址就可以理解成0x70000000 0x500核心思想就是起始地址 偏移量。九、問題來了代碼區(qū)不是只讀的嗎這里就出現(xiàn)一個(gè)很有意思的問題。程序中的.text一般是代碼區(qū)而代碼區(qū)不能隨便修改。但是動(dòng)態(tài)鏈接又需要在運(yùn)行時(shí)確定函數(shù)地址。那怎么辦總不能直接把.text里面的指令改來改去吧。于是就出現(xiàn)了GOTGlobal Offset Table全局偏移量表十、GOT到底是干什么的GOT 可以理解成程序?qū)ｉT準(zhǔn)備的一張“地址表”。它通常位于可讀寫的數(shù)據(jù)區(qū)域因此運(yùn)行時(shí)可以修改。里面保存的是程序當(dāng)前需要訪問的外部函數(shù)或者全局變量的地址。所以原來的思路代碼區(qū) ↓ 直接寫死外部函數(shù)地址變成代碼區(qū) ↓ 查GOT ↓ 找到真正地址 ↓ 跳過去這樣就不用直接修改代碼區(qū)。十一、為什么每個(gè)進(jìn)程都需要自己的GOT假設(shè)進(jìn)程A里面的libc.so加載到了0x70000000而進(jìn)程B里的libc.so可能加載到了另一個(gè)位置。那么進(jìn)程A里的GOT和進(jìn)程B里的GOT當(dāng)然不能完全一樣。所以動(dòng)態(tài)庫(kù)代碼本身可以共享但 GOT 不能簡(jiǎn)單地讓所有進(jìn)程共用。每個(gè)進(jìn)程都要根據(jù)自己的地址空間建立對(duì)應(yīng)關(guān)系。十二、PIC為什么和GOT有關(guān)動(dòng)態(tài)庫(kù)制作的時(shí)候我們執(zhí)行過gcc-fPIC-cmy_stdio.c以前只知道-fPIC就是生成位置無關(guān)代碼。現(xiàn)在再看就容易理解很多了。動(dòng)態(tài)庫(kù)需要能夠加載到不同的地址還要正常訪問其中的函數(shù)和數(shù)據(jù)這就需要相對(duì)尋址和 GOT 一起工作?？梢院?jiǎn)單記成PIC 相對(duì)編址 GOT這也是為什么生成動(dòng)態(tài)庫(kù)的時(shí)候需要-fPIC十三、PLT又是干什么的如果一個(gè)程序依賴很多動(dòng)態(tài)庫(kù)函數(shù)那么程序啟動(dòng)的時(shí)候把所有函數(shù)地址全部處理一遍會(huì)比較耗時(shí)間。假設(shè)程序依賴printf write close strlen ...但是實(shí)際運(yùn)行的時(shí)候可能只調(diào)用其中幾個(gè)。那一開始把所有函數(shù)都重定位一遍就有點(diǎn)浪費(fèi)了。所以又出現(xiàn)了一種優(yōu)化延遲綁定。對(duì)應(yīng)的就是PLTProcedure Linkage Table過程鏈接表十四、延遲綁定是怎么工作的一開始GOT中的函數(shù)地址 ↓ 輔助代碼第一次調(diào)用某個(gè)函數(shù)的時(shí)候調(diào)用函數(shù) ↓ 進(jìn)入PLT ↓ 查找真正函數(shù)地址 ↓ 修改GOT ↓ 跳轉(zhuǎn)到真正函數(shù)等第二次再調(diào)用調(diào)用函數(shù) ↓ PLT ↓ GOT里已經(jīng)有真正地址 ↓ 直接跳轉(zhuǎn)也就是說第一次調(diào)用的時(shí)候麻煩一點(diǎn)后面就可以直接用了。這樣就避免了程序啟動(dòng)時(shí)把大量暫時(shí)用不到的函數(shù)全部處理一遍。十五、把整個(gè)動(dòng)態(tài)鏈接過程串起來到這里可以把動(dòng)態(tài)鏈接整個(gè)過程串起來了。程序運(yùn)行./main↓讀取 ELF↓找到程序需要的 Segment↓建立進(jìn)程地址空間↓加載程序本身↓根據(jù)依賴關(guān)系找到動(dòng)態(tài)庫(kù)↓把動(dòng)態(tài)庫(kù)映射到當(dāng)前進(jìn)程地址空間↓確定動(dòng)態(tài)庫(kù)的加載地址↓處理 GOT↓調(diào)用動(dòng)態(tài)庫(kù)函數(shù)↓通過 PLT/GOT 找到真正地址↓進(jìn)入動(dòng)態(tài)庫(kù)函數(shù)執(zhí)行這樣整個(gè)過程就順起來了。十六、靜態(tài)鏈接和動(dòng)態(tài)鏈接放在一起最后再對(duì)比一下。靜態(tài)鏈接hello.o code.o 靜態(tài)庫(kù) ↓ 鏈接 ↓ 地址重定位 ↓ 獨(dú)立可執(zhí)行程序程序生成以后靜態(tài)庫(kù)本身不需要再參與運(yùn)行。動(dòng)態(tài)鏈接.o ↓ 生成可執(zhí)行程序 ↓ 程序運(yùn)行 ↓ 加載動(dòng)態(tài)庫(kù) ↓ 建立地址映射 ↓ GOT / PLT ↓ 調(diào)用動(dòng)態(tài)庫(kù)函數(shù)動(dòng)態(tài)鏈接把一部分工作放到了程序運(yùn)行的時(shí)候完成因此需要處理庫(kù)加載和運(yùn)行時(shí)地址重定位。十七、這部分知識(shí)終于串起來了以前看到.a .so ELF GOT PLT Segment Section感覺一個(gè)比一個(gè)陌生?，F(xiàn)在把它們按照程序運(yùn)行的順序排起來就比較容易理解源代碼 ↓ 編譯 ↓ .o ↓ 鏈接 ↓ ELF可執(zhí)行文件 ↓ 加載 ↓ 進(jìn)程地址空間 ↓ 動(dòng)態(tài)庫(kù) ↓ GOT ↓ PLT ↓ 真正的庫(kù)函數(shù)而靜態(tài)庫(kù)和動(dòng)態(tài)庫(kù)的區(qū)別也可以放在這里一起看靜態(tài)庫(kù) ↓ 鏈接階段進(jìn)入程序 動(dòng)態(tài)庫(kù) ↓ 運(yùn)行階段加載和處理這樣再去看ldd readelf objdump這些命令就不只是記它們的用法了而是知道自己到底在看什么。這一部分對(duì)我來說比較重要的一點(diǎn)就是開始慢慢把“編譯出來的文件”和“真正運(yùn)行起來的程序”聯(lián)系到了一起。