最近為了理解elf格式規(guī)范中的各種重定位類型,暈了。跑出去玩了幾天,終于為每種重定位類型,找到了對應的case。elf規(guī)范總共定義了10種重定位類型,之所以需要這么多種不同類型的重定位信息,是由于如下原因:
① 硬件對變量和函數(shù)的尋址方式不同,尋找變量要求絕對地址,尋找函數(shù)要求相對地址;
② 不同場合下,程序員對最終可執(zhí)行文件或動態(tài)庫的期望不一樣(位置無關、動態(tài)庫函數(shù)重定位延遲),從而加了不同的編譯選項(比如-fPIC、-Ox等);
③ C語言的static、extern特性,導致不同特性的變量或函數(shù)地址可以被確定的時機不同;
④ 內核加載可執(zhí)行文件,約定從固定地址0x80480000開始,但加載.so的起始地址無法約定(一個可執(zhí)行程序只有一個main(),但可能依賴多個動態(tài)庫)。
疑問:那整個系統(tǒng)中,可執(zhí)行程序也不只一個呀,都約定從相同的起始地址加載,不會沖突嗎?
因為每個進程訪問的都是虛擬地址,由內核在背后負責將不同進程的相同虛擬地址,映射到不同的實際物理地址(屬于內核范疇,不理解沒關系,不影響對本貼關鍵內容的理解)。
靜態(tài)鏈接/動態(tài)鏈接簡單理解
.c文件中的代碼最終被執(zhí)行,需要經(jīng)歷如下過程:
① 編譯:詞法解析 → 語法解析 → 靜態(tài)鏈接
② 加載:加載可執(zhí)行文件 → 可執(zhí)行文件啟動或執(zhí)行時,加載依賴的.so文件 → 動態(tài)鏈接
本帖僅關注靜態(tài)鏈接、動態(tài)鏈接過程,靜態(tài)鏈接與動態(tài)鏈接區(qū)別:
① 靜態(tài)鏈接處于將1個或多個.o文件“拼湊”成可執(zhí)行文件階段,處理對象是文件,文件中的代碼區(qū)沒有只讀屬性,鏈接過程中可以直接修改;動態(tài)鏈接處于可執(zhí)行文件或.so文件已被加載到內存階段,處理對象是內存,內核為代碼區(qū)所在的內存區(qū)域設置了只讀屬性,如果代碼區(qū)有內容需要重定位,需要在編譯或靜態(tài)鏈接時,事先準備一個間接位置(加載到內存不會被設置只讀屬性),動態(tài)鏈接是對該間接位置進行重定位。
② 通過下圖可以看出,靜態(tài)鏈接將.o的各個節(jié)“撕開”,屬性相同的節(jié)“拼湊”為可執(zhí)行文件的段;動態(tài)鏈接是將“整個”.so文件安排在與可執(zhí)行文件鏡像相獨立的位置(圖中最簡化了.o、.so、可執(zhí)行文件的內容,用于說明靜態(tài)鏈接與動態(tài)鏈接的區(qū)別,它們的內容遠遠不止.data、.text)。
另外,.so文件還涉及到位置無關(-fPIC)、延遲加載的選擇(應該是跟優(yōu)化級別有關),接下來即將詳細總結。
主要利用兩個技巧:
① 在程序編寫階段,雖然不知道以下兩條指令真正執(zhí)行后ebx寄存會得到什么值,但能確定它的含義是當時eip寄存器的值,那么跟這條指令相對位置固定的運行時地址,在邏輯上都能在編譯階段“獲知”:
call L1
L1: pop ebx
② 那么,在.so文件中相對于指令區(qū)域確定位置生成一個.got表,.so被執(zhí)行時.got表的絕對地址也是可以“獲知”的。這樣,就可以用.got表項的絕對地址,覆蓋原本在指令區(qū)域的重定位處,而.got表中存放將來才能確定的最終重定位的符號地址。
① 假設進程A先將libc.so映射到自己的一塊虛擬空間,當首次訪問這塊區(qū)間時發(fā)生缺頁異常,分配物理頁面并讀入內容,然后建立映射。接著,進程B也將libc.so映射到自己的一塊虛擬空間,首次訪問這塊區(qū)間仍然會發(fā)生缺頁異常,但與其建立映射的物理頁面,就不用再重新分配讀入了。從而,物理內存只需要一份.so的內容,就可以供A、B兩個進程使用。
② 思維敏銳的可能會發(fā)現(xiàn)一個問題:.so文件中如果有全局變量,被多個進程共享,不是會相互干擾嗎?
COW(寫時復制):內核為虛擬頁面、物理頁面都設置了一些屬性,比如如果對某個虛擬頁面進行寫操作,就重新分配一個物理頁面,復制內容并重新建立映射(為.so數(shù)據(jù)區(qū)分配的頁面,就具有這樣的屬性)。
③ 各個進程將.so文件映射到自己的虛擬空間,數(shù)據(jù)區(qū)、代碼區(qū)的相對位置,仍然保持和剛鏈接過后一致,所以在代碼區(qū)向.got的重定位計算仍然有效,只不過動態(tài)鏈接器為不同進程向.got表初始化全局變量的地址時,要向.got表進行寫操作,導致每個進程有一個.got副本。
6、b處兩條指令執(zhí)行后,ecx寄存器會得到.got表加載地址,為什么?
① 前面已經(jīng)說明過R_386_PC32重定位類型,7處經(jīng)過這種類型重定位后,執(zhí)行時會跳轉到__x86.get_pc_thunk.cx,得到b處指令的加載地址(CPU沒有提供直接獲取當前ip的指令,所以利用call會將返回地址壓棧的特點);
② R_386_GOTPC,提示鏈接器創(chuàng)建.got表,并修改d處的值,保證執(zhí)行時用它加ecx寄存器可以得到.got表地址(可以通過R_386_GLOB_DAT類型分析過程,編譯得到的.so驗證):
通過①可能確定,執(zhí)行過6處指令后ecx得到的b處指令的加載地址,拿什么和它相加可以得到.got表位置呢?
+A:從ecx所指位置往后推2字節(jié)(機器碼“81 c1”),就到了被重定位處(重定位項中的offset/規(guī)范文檔中的P);
+G-P:再向后推.got表相對此處的距離,就到.got表了。 注意:$0x2只是作為鏈接器計算重定位值的A,在執(zhí)行時就被G-P-2覆蓋了,不要疑惑為什么要從ecx減2,它的含義根本就不是減數(shù)。
① 532、537處(對應.o文件中6、b處)指令,確實可以將.got表位置計算到ecx寄存器中(不過是結束位置,后面指令取.got表項地址時,用的是負偏移,可能不同編譯器不一樣吧,用開始位置、結束位置計算,道理是一樣的);
② g1、g2的重定位類型變成R_386_GLOB_DAT,它是用于告訴動態(tài)鏈接器,在確定g1、g2地址時,放到它們的.got表項里(0x1fe8、0x1ff4)。