跑了好幾年的C程序換了個環(huán)境重新編譯后突然崩潰一個大工程把代碼拆分到幾十個文件后鏈接時報一堆“undefined reference”和“relocation truncated”之類的錯。這種場景我見得太多最后基本都是靜態(tài)鏈接和重定位的問題。靜態(tài)鏈接就是把一個個編譯好的目標(biāo)文件合并成最終可執(zhí)行程序的過程而重定位則負(fù)責(zé)把代碼里那些“占位”的地址引用按最終內(nèi)存布局修正成真實地址。這兩件事搞不明白很多鏈接期和運行初期的問題就只能靠猜。 這篇文章想做的事很簡單從靜態(tài)鏈接的完整流程講起把重定位表、重定位類型、地址計算規(guī)則一個個拆開再用一個能直接復(fù)現(xiàn)的小實驗把全過程演示一遍。適合正在被各種鏈接報錯折磨的C/C開發(fā)者也適合想系統(tǒng)理解編譯原理但不想啃太厚書的同學(xué)。內(nèi)容不依賴具體IDE用的就是Linux下的gcc和binutils打開終端就能跟練。 ## 1. 靜態(tài)鏈接做了件什么事從目標(biāo)文件到可執(zhí)行文件的“搬家” ### 1.1 編譯通過不代表程序能跑 很多人有個誤區(qū)覺得編譯通過了程序就萬事大吉結(jié)果一跑就崩或者一鏈接就報一些奇奇怪怪的錯誤。原因在于“編譯”和“鏈接”解決的是兩個層面的事。編譯階段編譯器只負(fù)責(zé)把單個.c文件翻譯成目標(biāo)文件.o它并不知道全局變量最終會放在哪個地址也不知道另一個文件里的函數(shù)被調(diào)用時該跳到哪里。目標(biāo)文件里的地址引用全是臨時的、相對的或者說全部是從零開始的“占位符”。 鏈接器的工作就是把這些分散的目標(biāo)文件合并起來安排它們在最終虛擬地址空間中的位置再把所有占位符替換成最終地址。這個過程如果只解決“能不能找到符號”還算簡單真正麻煩的是“每個符號最終到底落在哪個地址以及指令里怎么把這個地址填進(jìn)去”。后者就是重定位。 我用一個生活類比幫你建立直覺每個目標(biāo)文件就像一套毛坯房里的家具圖紙圖紙上標(biāo)注的尺寸和位置都是相對于本房間的而不是相對于整棟樓的。鏈接器是總設(shè)計師它把所有房間的家具圖紙匯總后確定每個房間在整棟樓的哪一層、哪個方位然后重新給每件家具計算絕對坐標(biāo)。那些“重新計算絕對坐標(biāo)”的動作落到二進(jìn)制層面就是重定位。 ### 1.2 鏈接器內(nèi)部的三個核心步驟 完整的一次靜態(tài)鏈接無論用的是ld還是前端包裝的gcc內(nèi)部大致都按下面三步推進(jìn)。 第一步是地址和空間分配。鏈接器掃描所有輸入目標(biāo)文件把它們的節(jié)section按類型合并。代碼節(jié)合并成大的.text數(shù)據(jù)節(jié)合并成大的.data和.bss然后決定這些合并后的節(jié)在最終虛擬地址空間中各自占據(jù)哪個區(qū)間。這一步的輸出是每個節(jié)、每個符號的最終虛擬地址。像鏈接腳本這類東西本質(zhì)就是干預(yù)這一步的地址安排。 第二步是符號解析。鏈接器建立一個全局符號表遍歷所有目標(biāo)文件里被引用的符號找到對應(yīng)的定義。如果某個符號在所有輸入文件里都找不到定義就會報undefined reference。如果多個文件定義了同一個全局符號就會報multiple definition。這里的規(guī)則簡單直接一個符號只能有一個定義但可以有無數(shù)個引用。 第三步才是重定位。根據(jù)前兩步得到的符號最終地址把指令和數(shù)據(jù)里那些占位的引用修正成可用的真實地址。對于x86-64平臺常見操作是把一條call指令后面的32位立即數(shù)從0改成實際計算出的偏移或者把一個全局變量的地址填進(jìn)數(shù)據(jù)段某個位置。 這三個步驟說起來簡單但每一步都有大量細(xì)節(jié)。比如地址空間分配階段要考慮對齊、權(quán)限標(biāo)志可讀可寫可執(zhí)行、節(jié)順序符號解析階段要處理強弱符號、公共塊common block、靜態(tài)庫的按需抽取重定位階段要區(qū)分PC相對引用和絕對引用、不同的重定位類型、甚至代碼模型code model的影響。 ### 1.3 靜態(tài)鏈接與動態(tài)鏈接的分工差異 有人會問既然靜態(tài)鏈接這么復(fù)雜為什么現(xiàn)代系統(tǒng)還在大量使用動態(tài)鏈接因為兩者解決的問題側(cè)重不同。動態(tài)鏈接把一部分地址解析推遲到程序加載時甚至函數(shù)首次調(diào)用時允許多個進(jìn)程共享一份.so的代碼段節(jié)省內(nèi)存也讓庫的升級不用重新編譯所有依賴它的程序。代價是運行時要多一層解析開銷且存在被依賴庫版本替換的兼容性問題。 靜態(tài)鏈接的優(yōu)勢則是“焊死”所有符號地址在鏈接完成時就已確定程序不依賴運行環(huán)境里的任何共享庫部署簡單啟動也快。在嵌入式開發(fā)、容器單二進(jìn)制工具、隔離環(huán)境等場景里靜態(tài)鏈接至今仍是首選。這里需要澄清一個常見錯覺靜態(tài)鏈接不等于非得用靜態(tài)庫.a。直接把多個.o文件鏈接成可執(zhí)行文件同樣屬于靜態(tài)鏈接。所以哪怕你不用-lxxx你的程序也一直在經(jīng)歷靜態(tài)鏈接和重定位的過程。 動態(tài)鏈接也不是完全不重定位它只是把一部分重定位放到了運行時由動態(tài)鏈接器ld.so去處理。靜態(tài)鏈接的重定位是“鏈接期一次算清楚”動態(tài)鏈接的很多重定位是“加載時每進(jìn)程算一次”。理解了靜態(tài)重定位再看動態(tài)重定位會輕松很多因為底層計算規(guī)則是互通的。 ## 2. 重定位的核心機制報錯里那串“天書”其實不難懂 ### 2.1 重定位表鏈接器的“待辦清單” 每個目標(biāo)文件里都有一組重定位表在ELF文件里通常叫.rela.text、.rela.data分別對應(yīng)代碼節(jié)的引用修正和數(shù)據(jù)節(jié)的引用修正。這里的.rela前綴代表“有顯式加數(shù)Addend的重定位”x86-64平臺基本都用這種格式。早期一些架構(gòu)如32位x86默認(rèn)用.rel格式重定位信息里不帶加數(shù)加數(shù)要從被修正位置的既有內(nèi)容里讀出來兩種格式容易混淆看readelf輸出時留意一下就行。 用readelf -r main.o查看重定位表時你會看到一串條目核心字段是三個 - Offset需要被修正的位置也就是指令或數(shù)據(jù)里那個占位符所在處的偏移。 - Info高32位是符號在符號表里的索引低32位是重定位類型。它把“要修正成誰”和“按什么規(guī)則修正”打包在了一起。 - Addend一個附加常量參與最終地址計算不同重定位類型用法不同。 這三個字段合起來就是鏈接器的一條待辦清單在Offset這個位置拿Info指定的符號按某種類型規(guī)則加上Addend算出結(jié)果填回去。理解重定位的第一步就是看懂這張清單。 ### 2.2 最常見的幾種重定位類型與計算公式 x86-64下重定位類型非常多但絕大多數(shù)日常工程只會遇到下面這幾種。每種類型對應(yīng)一條計算公式S代表符號的最終地址A代表加數(shù)P代表被修正位置自身的地址B代表共享對象加載時的基地址。 - R_X86_64_PC32結(jié)果 S A - P。這是PC相對引用常用于函數(shù)調(diào)用和rip相對尋址的全局變量訪問。指令里保存的是“目標(biāo)地址相對于下一條指令的偏移”優(yōu)點是鏈接后的代碼天然支持加載到不同基址安全性更好。 - R_X86_64_32 / R_X86_64_32S結(jié)果 S A即把符號的絕對地址作為一個32位值填進(jìn)去。這類絕對引用通常要求目標(biāo)地址在低2GB或者可被32位有符號數(shù)表達(dá)。非PIC代碼訪問全局變量時可能出現(xiàn)這種類型。 - R_X86_64_64結(jié)果 S A以一個完整的64位指針形式填入常見于數(shù)據(jù)段里存放函數(shù)指針的場景。 - R_X86_64_RELATIVE結(jié)果 B A動態(tài)鏈接中的基址相對重定位。PIE或共享庫加載時動態(tài)鏈接器用這個公式在運行時修正地址。 調(diào)匯編時最容易遇到的是PC32。x86的call指令格式是E8 4字節(jié)偏移位移的計算基準(zhǔn)是“下一條指令的地址”而不是call指令自身地址。所以編譯器生成引用時Addend通常要寫成-4把指令長度扣掉。鏈接器算S A - P時這個-4正好抵消掉指令長度最后填進(jìn)去的偏移才是處理器預(yù)期的。很多新手手工計算重定位結(jié)果時總是多出4個字節(jié)原因就是忽略了這條約定。 | 重定位類型 | 計算公式 | 典型場景 | 修正時機 | | --- | --- | --- | --- | | R_X86_64_PC32 | S A - P | call指令、rip相對數(shù)據(jù)訪問 | 靜態(tài)鏈接期 | | R_X86_64_32 / 32S | S A | 非PIC代碼的絕對地址訪問 | 靜態(tài)鏈接期 | | R_X86_64_64 | S A | 數(shù)據(jù)段中的64位指針 | 靜態(tài)鏈接期 | | R_X86_64_RELATIVE | B A | PIE、共享庫的運行時重定位 | 動態(tài)鏈接器加載時 | ### 2.3 PC相對引用與絕對引用的取舍 看到這里你應(yīng)該發(fā)現(xiàn)同樣是訪問一個符號編譯器既可能生成PC相對引用也可能生成絕對引用。編譯器選擇哪種方式取決于編譯選項、目標(biāo)平臺和代碼模型。PC相對引用的優(yōu)勢在于結(jié)果與加載基址無關(guān)程序被映射到哪個地址都能跑缺點是32位偏移表達(dá)范圍只有正負(fù)2GB如果代碼段和數(shù)據(jù)段相隔太遠(yuǎn)就會溢出報出經(jīng)典的relocation truncated to fit。 絕對引用的優(yōu)勢是表達(dá)范圍更大用64位時可以覆蓋整個地址空間而且不需要一條額外指令去做相對到絕對的換算缺點是把死的地址寫進(jìn)了代碼里一旦程序作為PIE被加載到隨機基址這份代碼就無法運行?，F(xiàn)代Linux發(fā)行版默認(rèn)開啟PIE所以編譯器傾向于生成PC相對引用。這也解釋了為什么同一份代碼在老的默認(rèn)非PIE環(huán)境和新默認(rèn)PIE環(huán)境下重定位表的輸出會有明顯差異。 絕對引用和PC相對引用沒有絕對的好壞關(guān)鍵是理解當(dāng)前項目的運行模型。如果你在寫內(nèi)核、bootloader這類鏈接地址固定、且不依賴ASLR的軟件絕對引用反而常見。如果你在寫普通的Linux用戶態(tài)程序則默認(rèn)按PIE考慮多關(guān)注PC32和RELATIVE。 ## 3. 實操親手做一次完整重定位把地址修正的前后對比看清楚 ### 3.1 準(zhǔn)備實驗環(huán)境 整個實驗只需要Linux系統(tǒng)、gcc和binutilsUbuntu/Debian這類發(fā)行版默認(rèn)都齊全。實驗?zāi)夸浗▋蓚€文件邏輯盡量簡單便于觀察。foo.c定義了一個全局變量和一個函數(shù)main.c負(fù)責(zé)調(diào)用它們。 foo.c c int global_var 100; int foo(int x) { return x global_var; }main.c#include stdio.h extern int global_var; int foo(int); int main(void) { int result foo(1); global_var; printf(result%d\n, result); return 0; }注意main.c里對global_var用了extern聲明而不是重新定義一個變量。如果寫int global_var;在C語言里這屬于tentative definition某些編譯參數(shù)下可能與foo.c里的定義產(chǎn)生沖突這是后面常見錯誤章節(jié)要討論的經(jīng)典坑。3.2 編譯目標(biāo)文件查看“零地址”占位狀態(tài)執(zhí)行g(shù)cc -c main.c foo.c得到main.o和foo.o。接著用readelf查看main.o的重定位表readelf -r main.o在我當(dāng)前環(huán)境里輸出大致是這樣Relocation section .rela.text at offset 0x1a8 contains 4 entries: Offset Info Type Sym. Value Sym. Name Addend 000000000000000e 0000000300000002 R_X86_64_PC32 0000000000000000 foo - 4 0000000000000019 0000000400000002 R_X86_64_PC32 0000000000000000 global_var - 4 000000000000002f 0000000500000002 R_X86_64_PC32 0000000000000000 printf - 4三條重定位都集中在.Rela.text里對應(yīng)main函數(shù)中對foo函數(shù)、global_var變量和printf函數(shù)的引用。再看objdump反匯編objdump -dr main.o輸出里的關(guān)鍵部分是這樣的e: e8 00 00 00 00 call 13 main0x13 f: R_X86_64_PC32 foo-0x4 19: 8b 05 00 00 00 00 mov 0x0(%rip),%eax 1b: R_X86_64_PC32 global_var-0x4call指令后面跟著的00 00 00 00就是占位符反匯編器提示這個位置有一處對foo的重定位。注意第二行的mov指令它從rip寄存器取地址再加一個32位偏移來讀global_var這就是典型的PC相對數(shù)據(jù)訪問。所有這些偏移現(xiàn)在都是0鏈接器還沒有修正它們。3.3 鏈接后觀察地址如何被“焊死”執(zhí)行鏈接gcc -o app main.o foo.o再反匯編查看main函數(shù)objdump -d app可以看到call指令后面的四個字節(jié)已經(jīng)被填成了具體值比如call 401136。對比main.o里還是00 00 00 00的狀態(tài)這就是重定位的直觀證據(jù)。還可以用readelf查看可執(zhí)行文件的ELF頭readelf -h app | grep Type現(xiàn)代Linux發(fā)行版默認(rèn)PIE所以Type通常是DYN而不是傳統(tǒng)的EXEC。DYN類型意味著這個可執(zhí)行文件在加載時會被動態(tài)鏈接器放到一個隨機基址上代碼里的PC相對引用不需要修正直接在加載地址偏移下就能運行。再驗證一下靜態(tài)鏈接完成后的狀態(tài)readelf -r app | head可執(zhí)行文件里通常已經(jīng)不存在靜態(tài)重定位表只剩下動態(tài)加載需要處理的.rela.dyn和.rela.plt。這說明鏈接期的重定位工作已經(jīng)全部完成。3.4 加-fPIC重新編譯對比重定位類型的變化把foo.c用位置無關(guān)代碼方式編譯再試一次gcc -c -fPIC foo.c gcc -o app2 main.o foo.o readelf -r foo.o如果只編譯目標(biāo)文件不鏈接foo.o里訪問global_var的代碼會生成R_X86_64_PC32重定位但如果繼續(xù)做動態(tài)庫或PIE鏈接部分引用會在進(jìn)一步處理中保留或轉(zhuǎn)化為其他類型。重點觀察的是編譯選項會直接改變目標(biāo)文件里的重定位類型集合比如對全局變量的普通訪問在-fno-pic下可能生成R_X86_64_32S而-fPIC下變成PC相對訪問或走GOT。這個對比實驗做完你就能建立一條判斷線索看到R_X86_64_PC32說明是PC相對引用看到R_X86_64_32S說明是絕對引用看到R_X86_64_RELATIVE說明需要在加載時基于基址修正。不同PIE選項、代碼模型、編譯器版本產(chǎn)生的組合非常多但底層邏輯是一致的。4. 常見錯誤與實戰(zhàn)排查這五種坑一定要躲開4.1 relocation truncated to fit地址超出表達(dá)范圍這類報錯的完整格式類似relocation truncated to fit: R_X86_64_PC32 against symbol foo含義是鏈接器算出來的結(jié)果超出了目標(biāo)重定位類型所能表達(dá)的范圍。PC32是32位有符號數(shù)只能表達(dá)正負(fù)2GB32S是32位有符號數(shù)也只能覆蓋約正負(fù)2GB。當(dāng)程序代碼段和數(shù)據(jù)段之間距離超出這個范圍或者單個節(jié)實在太大時就會觸發(fā)。遇到這類錯誤先反思是不是引入了超大的全局結(jié)構(gòu)體、把超大數(shù)組放在了不該放的位置或者鏈接腳本里把某些段放得離.text太遠(yuǎn)。嵌入式工程師經(jīng)常踩這個坑因為Flash和RAM在地址空間里相隔非常遠(yuǎn)訪問全局變量或調(diào)用函數(shù)時容易跨界。臨時方案可以加代碼模型參數(shù)比如gcc的-mcmodellarge但它會讓所有地址訪問變慢、代碼體積變大只能作為過渡。真正穩(wěn)妥的方案是調(diào)整數(shù)據(jù)布局或者把代碼拆開把相互訪問頻繁的模塊放到同一區(qū)域內(nèi)。4.2 multiple definition全局變量被定義了好幾次很多人都會遇到這樣的報錯multiple definition of global_var最常見原因是頭文件里寫了變量定義比如int cfg_flag 0;然后多個.c文件包含這個頭文件于是一個符號在多份目標(biāo)文件里都出現(xiàn)了定義。C語言里這屬于未定義行為但老式編譯器為了兼容會把這種定義當(dāng)作common處理默認(rèn)不報錯現(xiàn)代工具鏈越收越緊默認(rèn)會出現(xiàn)多重定義報錯。解決方案看起來很簡單頭文件里只寫extern聲明真正的定義放在某個.c文件里。但要注意C語言還有一個隱蔽的tentative definition規(guī)則在一個.c文件里寫int x;而沒有初始化器時它既是聲明也是“暫定定義”如果多個.c都寫了int x;鏈接器會把它們合并成一個common塊。加了-fno-common編譯參數(shù)后這條寬松路徑會被封死多重定義暴露得更早。想要代碼跨平臺、跨工具鏈都穩(wěn)定就別依賴這個規(guī)則寧可多寫一個extern。4.3 undefined reference與靜態(tài)庫的鏈接順序又是經(jīng)典中的經(jīng)典尤其是新手undefined reference to foo符號明明定義了為什么沒被解析到這里十有八九是靜態(tài)庫順序問題。鏈接器處理參數(shù)的方式是從左到右掃描每遇到一個未定義符號就記在待解析列表里只有遇到包含該符號定義的庫或目標(biāo)文件時才會接管這個符號。如果靜態(tài)庫放在源文件、目標(biāo)文件之前鏈接器在解析到庫時還不知道后面會有人引用它可能直接跳過整個庫文件后面對這個庫的引用就全成了undefined。解決方法是把-lxxx參數(shù)放在所有.o文件之后。比如gcc -o app main.o libfoo.a而不要寫成gcc -o app libfoo.a main.o如果多個靜態(tài)庫之間有互相依賴還需要按依賴關(guān)系排列庫的順序甚至重復(fù)寫庫名。CMake里target_link_libraries的書寫順序同樣要謹(jǐn)慎cmake的鏈接器包裝腳本盡量幫你做了一部分排序處理但跨平臺構(gòu)建時還是可能出問題。另外.so動態(tài)庫在運行時由整個進(jìn)程統(tǒng)一解析沒有這個順序問題容易讓人混淆。4.4 --gc-sections把符號裁掉了很多工程喜歡用鏈接期垃圾回收減少最終體積典型參數(shù)是-Wl,--gc-sections。這會把沒有被引用到的節(jié)整體裁掉但某些節(jié)是被匯編、鏈接腳本或特性注冊機制間接引用的鏈接器看不到這些引用于是誤判為無用并刪除。表現(xiàn)有兩種鏈接成功但運行時崩潰或找不到符號鏈接時明明看到目標(biāo)文件里有該符號卻報undefined reference。很多注冊表模式的模塊比如用__attribute__((constructor))自動注冊的驅(qū)動、異常展開表、段表項都會撞上這個問題。解決方式很明確對需要保留的符號或節(jié)加__attribute__((used))在匯編里用.globl和.type聲明在鏈接腳本里用KEEP()顯式保留。排查時先用nm查看目標(biāo)文件里的符號是否還在再看最終可執(zhí)行文件里是否被GC掉基本能一步定位。盲目加--no-gc-sections也行但體積會明顯膨脹不如定位到具體符號后精準(zhǔn)保留。4.5 可執(zhí)行文件里符號被“吃掉”或被迫加前綴鏈接時偶爾會碰到這樣的問題目標(biāo)文件里符號名是foo鏈接后卻變成foo.local、foo.part.0這種樣子的名字或者明明調(diào)用了foo但在符號表里找不到對應(yīng)項。這類情況多與編譯器優(yōu)化、內(nèi)聯(lián)、局部符號折疊有關(guān)也可能和-fvisibilityhidden以及版本腳本有關(guān)。如果是動態(tài)庫導(dǎo)出符號找不到檢查一下編譯時有沒有用-fvisibilityhidden把默認(rèn)可見性改成隱藏以及version script里有沒有顯式列出導(dǎo)出符號。這類問題在現(xiàn)代大型C項目里特別常見因為默認(rèn)隱藏符號可以顯著減小導(dǎo)出表體積但也容易把本該導(dǎo)出的接口一起隱藏掉。看完導(dǎo)出表就基本能鎖定問題。5. 進(jìn)階重定位在PIE、PIC和鏈接腳本下另有玄機5.1 為什么現(xiàn)代Linux默認(rèn)PIE傳統(tǒng)可執(zhí)行文件EXEC類型鏈接時會指定一個固定加載地址比如0x400000程序被操作系統(tǒng)加載時通常就放在這個固定位置。問題在于如果地址固定攻擊者就可以預(yù)測內(nèi)存布局結(jié)合其他漏洞實施地址固定的攻擊。地址空間布局隨機化ASLR要發(fā)揮作用程序本身必須能被加載到隨機選擇的基址上這就要求可執(zhí)行文件在加載時能容忍基址漂移。PIEPosition Independent Executable就是為解決這個問題而生的。PIE可執(zhí)行文件被加載到任意基址都能正常工作因為代碼里的引用要么是PC相對地址要么在加載時通過動態(tài)重定位修正。從重定位類型看PIE可執(zhí)行文件的動態(tài)節(jié)里會出現(xiàn)R_X86_64_RELATIVE這個類型使用B A公式由動態(tài)鏈接器在程序啟動時根據(jù)實際基址B來修正。代價是啟動時多了一點點動態(tài)修正時間代碼生成也受限但換來的安全收益在現(xiàn)代互聯(lián)網(wǎng)環(huán)境下非常值得。理解這一點有助于看懂自己的程序在地址和重定位上的真實狀態(tài)。如果你在排查一個PIE程序的崩潰第一反應(yīng)不應(yīng)該假設(shè)里面某個指針是絕對固定地址而是要意識到加載基址每次運行都可能不同。5.2 PIC代碼如何繞開重定位GOT與PLTPIC位置無關(guān)代碼主要用于共享庫目標(biāo)是讓一份代碼段能被多個進(jìn)程安全共享。如果代碼里寫死了某條絕對地址每個進(jìn)程加載基址不同該地址就只對當(dāng)前進(jìn)程有效這份代碼段就沒法在多個進(jìn)程間共享了。解決思路是把所有可能變化的地址放進(jìn)一個數(shù)據(jù)段里的全局偏移表GOT代碼里只間接訪問GOT。訪問外部全局變量時編譯器生成“通過GOT讀地址再通過該地址取變量”的指令序列。動態(tài)鏈接器在加載共享庫時負(fù)責(zé)把GOT里的條目修正為每個進(jìn)程各自的正確地址。調(diào)用外部函數(shù)時PC32無法直接解析所以引入PLT調(diào)用指令不直接跳向目標(biāo)函數(shù)而先跳到PLT樁PLT樁再從GOT取出真實函數(shù)地址。啟用延遲綁定時第一次調(diào)用還會先進(jìn)入動態(tài)鏈接器的解析器解析完成后把真實地址寫回GOT后續(xù)調(diào)用直接跳走。代價也明顯每次通過GOT訪問外部符號都多了一次內(nèi)存讀取和可能的跳轉(zhuǎn)性能比靜態(tài)鏈接直接調(diào)用差一些。這解釋了為什么性能敏感的庫里有些優(yōu)化技術(shù)會盡量把外部符號在模塊內(nèi)部先做一次地址緩存。5.3 鏈接腳本決定最終布局也就決定了重定位結(jié)果默認(rèn)情況下ld會使用內(nèi)置鏈接腳本?？梢杂胠d --verbose查看內(nèi)容里面定義了.text、.data、.bss等節(jié)在虛擬地址空間里的排列順序。嵌入式和內(nèi)核開發(fā)里人們經(jīng)常自定義鏈接腳本指定代碼段放在0x08000000這樣的Flash地址數(shù)據(jù)段放在0x20000000這樣的RAM地址。鏈接腳本的排布直接決定了S的最終值也決定了各種重定位計算結(jié)果。如果腳本把某段數(shù)據(jù)放到離代碼段超過2GB的地方PC32引用就會溢出。反過來也可以通過調(diào)整腳本讓相互引用的節(jié)靠攏從根源上規(guī)避一部分truncated錯誤。在單片機開發(fā)中VMA虛擬地址即運行時代碼所在位置和LMA加載地址即代碼燒錄位置經(jīng)常不同比如代碼運行在RAM但初始化數(shù)據(jù)存在Flash里。重定位修正的是VMA啟動代碼則要把.data從LMA拷貝到VMA這個過程如果沒做對就會出現(xiàn)“鏈接都過了、上電就飛”的現(xiàn)象。很多工具鏈的通用做法是先用一個粗略鏈接腳本看地址范圍是否合理再用map文件核對關(guān)鍵符號的位置。對地址分布沒有掌控力就很難談?wù)嬲斫馇度胧较到y(tǒng)的啟動過程。排查重定位問題多了我自己形成了一套固定套路先看報錯類型是溢出還是多重定義還是未定義引用然后查map文件用-Wl,-Mapapp.map生成最終地址清單最后再用readelf -r、objdump -dr還原目標(biāo)文件里的重定位表逐條核對。這套流程比瞎改編譯選項高效得多。鏈接器不是黑魔法它的報錯幾乎每個都有明確出處重定位表就是它的“底稿”。搞懂這套機制后你再看那些天書一樣的鏈接報錯會覺得它們比運行時崩潰友好得多。