【導(dǎo)讀】：編譯與鏈接對C&C++程序員既熟悉又陌生，熟悉在于每份代碼都要經(jīng)歷編譯與鏈接過程，陌生在于大部分人并不會刻意關(guān)注編譯與鏈接的原理。本文通過開發(fā)過程中碰到的四個(gè)典型問題來探索64位linux下C++編譯&鏈接的那些事。

以下是正文

編譯原理

將如下最簡單的C++程序（main.cpp）編譯成可執(zhí)行目標(biāo)程序，實(shí)際上可以分為四個(gè)步驟：預(yù)處理、編譯、匯編、鏈接，可以通過

g++ main.cpp –v看到詳細(xì)的過程，不過現(xiàn)在編譯器已經(jīng)把預(yù)處理和編譯過程合并。

預(yù)處理：g++ -E main.cpp -o main.ii，-E表示只進(jìn)行預(yù)處理。預(yù)處理主要是處理各種宏展開；添加行號和文件標(biāo)識符，為編譯器產(chǎn)生調(diào)試信息提供便利；刪除注釋；保留編譯器用到的編譯器指令等。

編譯：g++ -S main.ii –o main.s，-S表示只編譯。編譯是在預(yù)處理文件基礎(chǔ)上經(jīng)過一系列詞法分析、語法分析及優(yōu)化后生成匯編代碼。

匯編：g++ -c main.s –o main.o。匯編是將匯編代碼轉(zhuǎn)化為機(jī)器可以執(zhí)行的指令。

鏈接：g++ main.o。鏈接生成可執(zhí)行程序，之所以需要鏈接是因?yàn)槲覀兇a不可能像main.cpp這么簡單，現(xiàn)代軟件動則成百上千萬行，如果寫在一個(gè)main.cpp既不利于分工合作，也無法維護(hù)，因此通常是由一堆cpp文件組成，編譯器分別編譯每個(gè)cpp，這些cpp里會引用別的模塊中的函數(shù)或全局變量，在編譯單個(gè)cpp的時(shí)候是沒法知道它們的準(zhǔn)確地址，因此在編譯結(jié)束后，需要鏈接器將各種還沒有準(zhǔn)確地址的符號（函數(shù)、變量等）設(shè)置為正確的值，這樣組裝在一起就可以形成一個(gè)完整的可執(zhí)行程序。

問題一：頭文件遮擋

在編譯過程中最詭異的問題莫過于頭文件遮擋，如下代碼中main.cpp包含頭文件common.h，真正想用的頭文件是圖中最右邊那個(gè)包含name

成員的文件（所在目錄為。/include），但在編譯過程中中間的common.h（所在目錄為。/include1）搶先被發(fā)現(xiàn)，導(dǎo)致編譯器報(bào)錯(cuò)：Test結(jié)構(gòu)沒有name成員，對程序員來講，自己明明定義了name成員，居然說沒有name這個(gè)成員，如果第一次碰到這種情況可能會懷疑人生。應(yīng)對這種詭異的問題，我們可以用-E參數(shù)看下編譯器預(yù)處理后的輸出，如下圖。

預(yù)處理文件格式如下：# linenum filename flag，表示之后的內(nèi)容是從文件名為filaname的文件中第linenum行展開的，flag的取值可以是1，2，3，4，可以是用空格分開的多值，1表示接下來要展開一個(gè)新文件；2表示一個(gè)文件展開完畢；3表示接下來內(nèi)容來自一個(gè)系統(tǒng)頭文件；4表示接下來的內(nèi)容應(yīng)該看做是extern C形式引入的。

從展開后的輸出我們可以清楚地看到Test結(jié)構(gòu)確實(shí)沒有定義name這個(gè)成員，并且Test這個(gè)結(jié)構(gòu)是在。/include1中的common.h中定義的，到此真相大白，編譯器壓根就沒用我們定義的Test結(jié)構(gòu)，而是被別的同名頭文件截胡了。我們可以通過調(diào)整-I或者在頭文件中帶上部分路徑更詳細(xì)制定頭文件位置來解決。

目標(biāo)文件：

編譯鏈接最終會生成各種目標(biāo)文件，Linux下目標(biāo)文件格式為ELF（Executable Linkable Format），詳細(xì)定義見/usr/include/elf.h頭文件，常見的目標(biāo)文件有：可重定位目標(biāo)文件，也即.o結(jié)尾的目標(biāo)文件，當(dāng)然靜態(tài)庫也歸為此類；可執(zhí)行文件，比如默認(rèn)編譯出的a.out文件；共享目標(biāo)文件.so；核心轉(zhuǎn)儲文件，也就是core dump后產(chǎn)出的文件。Linux文件格式可以通過file命令查看。

一個(gè)典型的ELF文件格式如下圖所示，文件有兩種視角：編譯視角，以section頭部表為核心組織程序；運(yùn)行視角，程序頭部表以segment為核心組織程序。這么做主要是為了節(jié)約存儲，很多細(xì)碎的section在運(yùn)行時(shí)由于對齊要求會導(dǎo)致很大的內(nèi)存浪費(fèi)，運(yùn)行時(shí)通常會將權(quán)限類似的section組織成segment一起加載。

通過命令objdump和readelf可以查看ELF文件的內(nèi)容。

對可重定位目標(biāo)文件常見的section有：

符號解析：

鏈接器會為對外部符號的引用修改為正確的被引用符號的地址，當(dāng)無法為引用的外部符號找到對應(yīng)的定義時(shí)，鏈接器會報(bào)undefined reference to XXXX的錯(cuò)誤。另外一種情況是，找到了多個(gè)符號的定義，這種情況鏈接器有一套規(guī)則。在描述規(guī)則前需要了解強(qiáng)符號和弱符號的概念，簡單講函數(shù)和已初始化的全局變量是強(qiáng)符號，未初始化的全局變量是弱符號。

針對符號的多重定義鏈接器處理規(guī)則如下（作者在gcc 7.3.0上貌似規(guī)則2，3都按1處理）：

1. 不允許多個(gè)強(qiáng)符號定義，鏈接器會報(bào)告重復(fù)定義貌似的錯(cuò)誤

2. 如果一個(gè)強(qiáng)符號和多個(gè)弱符號同名，則選擇強(qiáng)符號

3. 如果符號在所有目標(biāo)文件中都為弱符號，那么選擇占用空間最大的一個(gè)

有了這些基礎(chǔ)，我們先來看一下靜態(tài)鏈接過程：

1. 鏈接器從左到右按照命令行出現(xiàn)順序掃描目標(biāo)文件和靜態(tài)庫

2. 鏈接器維護(hù)一個(gè)目標(biāo)文件的集合E，一個(gè)未解析符號集合U，以及E中已定義的符號集合D，初始狀態(tài)E、U、D都為空

3. 對命令行上每個(gè)文件f，鏈接器會判斷f是否是一個(gè)目標(biāo)文件還是靜態(tài)庫，如果是目標(biāo)文件，則f加入到E，f中未定義的符號加入到U中，已定義符號加入到D中，繼續(xù)下一文件

4. 如果是靜態(tài)庫，鏈接器嘗試到靜態(tài)庫目標(biāo)文件中匹配U中未定義的符號，如果m中匹配U中的一個(gè)符號，那么m就和上步中文件f一樣處理，對每個(gè)成員文件都依次處理，直到U、D無變化，不包含在E中的成員文件簡單丟棄

5. 所有輸入文件處理完后，如果U中還有符號，則出錯(cuò)，否則鏈接正常，輸出可執(zhí)行文件

問題二：靜態(tài)庫順序

如下圖所示，main.cpp依賴liba.a，liba.a又依賴libb.a，根據(jù)靜態(tài)鏈接算法，如果用g++ main.cpp liba.a libb.a的順序能正常鏈接，因?yàn)榻馕鰈iba.a時(shí)未定義符號FunB會加入到上述算法的U中，然后在libb.a中找到定義。

如果用g++ main.cpp libb.a liba.a的順序編譯，則無法找到FunB的定義，因?yàn)楦鶕?jù)靜態(tài)鏈接算法，在解析libb.a的時(shí)候U為空，所以不需要做任何解析，簡單拋棄libb.a，但在解析liba.a的時(shí)候又發(fā)現(xiàn)FunB沒有定義，導(dǎo)致U最終不為空，鏈接錯(cuò)誤。

因此在做靜態(tài)鏈接時(shí)，需要特別注意庫的順序安排，引用別的庫的靜態(tài)庫需要放在前面，碰到鏈接很多庫的時(shí)候，可能需要做一些庫的調(diào)整，從而使依賴關(guān)系更清晰。

動態(tài)鏈接：

之前大部分內(nèi)容都是靜態(tài)鏈接相關(guān)，但靜態(tài)鏈接有很多不足：不利于更新，只要有一個(gè)庫有變動，都需要重新編譯；不利于共享，每個(gè)可執(zhí)行程序都單獨(dú)保留一份，對內(nèi)存和磁盤是極大的浪費(fèi)。

要生成動態(tài)鏈接庫需要用到參數(shù)“-shared -fPIC”表示要生成位置無關(guān)PIC（Position Independent Code）的共享目標(biāo)文件。對靜態(tài)鏈接，在生成可執(zhí)行目標(biāo)文件時(shí)整個(gè)鏈接過程就完成了，但要想實(shí)現(xiàn)動態(tài)鏈接的效果，就需要把程序按照模塊拆分成相對獨(dú)立的部分。

在程序運(yùn)行時(shí)將他們鏈接成一個(gè)完整的程序，同時(shí)為了實(shí)現(xiàn)代碼在不同程序間共享要保證代碼是和位置無關(guān)的（因?yàn)楣蚕砟繕?biāo)文件在每個(gè)程序中被加載的虛擬地址都不一樣，要保證它不管被加載在哪都能工作），而為了實(shí)現(xiàn)位置無關(guān)又依賴一個(gè)前提：數(shù)據(jù)段和代碼段的距離總是保持不變。

由于不管在內(nèi)存中如何加載一個(gè)目標(biāo)模塊，數(shù)據(jù)段和代碼段間的距離是不變的，編譯器在數(shù)據(jù)段前面引入了一個(gè)全局偏移表GOT（Global Offset Table），被引用的全局變量或者函數(shù)在GOT中都有一條記錄，同時(shí)編譯器為GOT中每個(gè)條目生成一個(gè)重定位記錄，因?yàn)閿?shù)據(jù)段是可以修改的，動態(tài)鏈接器在加載時(shí)會重定位GOT中的每個(gè)條目，這樣就實(shí)現(xiàn)了PIC。

大體原理基本就這樣，但具體實(shí)現(xiàn)時(shí)，對函數(shù)的處理和全局變量有所不同。由于大型程序函數(shù)成千上萬，而程序很可能只會用到其中的一小部分，因此沒必要加載的時(shí)候把所有的函數(shù)都做重定位，只有在用到的時(shí)候才對地址做修訂。

為此編譯器引入了過程鏈接表PLT（Procedure Linkage Table）來實(shí)現(xiàn)延時(shí)綁定。PLT在代碼段中，它指向了GOT中函數(shù)對應(yīng)的地址，第一次調(diào)用時(shí)候，GOT存放的不是函數(shù)的實(shí)際地址，而是PLT跳轉(zhuǎn)到GOT代碼的后一條指令地址。

這樣第一次通過PLT跳轉(zhuǎn)到GOT，然后通過GOT又調(diào)回到PLT的下一條指令，相當(dāng)于什么也沒做，緊接著PLT后面的代碼會將動態(tài)鏈接需要的參數(shù)入棧，然后調(diào)用動態(tài)鏈接器修正GOT中的地址，從這以后，PLT中代碼跳轉(zhuǎn)到GOT的地址就是函數(shù)真正的地址，從而實(shí)現(xiàn)了所謂的延時(shí)綁定。

對共享目標(biāo)文件而言，有幾個(gè)需要關(guān)注的section：

有了以上基礎(chǔ)后，我們看一下動態(tài)鏈接的過程：

1. 裝載過程中程序執(zhí)行會跳轉(zhuǎn)到動態(tài)鏈接器

2. 動態(tài)鏈接器自舉通過GOT、.dynamic信息完成自身的重定位工作

3. 裝載共享目標(biāo)文件：將可執(zhí)行文件和鏈接器本身符號合并入全局符號表，依次廣度優(yōu)先遍歷共享目標(biāo)文件，它們的符號表會不斷合并到全局符號表中，如果多個(gè)共享對象有相同的符號，則優(yōu)先載入的共享目標(biāo)文件會屏蔽掉后面的符號

4. 重定位和初始化

問題三：全局符號介入

動態(tài)鏈接過程中最關(guān)鍵的第3步可以看到，當(dāng)多個(gè)共享目標(biāo)文件中包含一個(gè)相同的符號，那么會導(dǎo)致先被加載的符號占住全局符號表，后續(xù)共享目標(biāo)文件中相同符號被忽略。當(dāng)我們代碼中沒有很好的處理命名的話，會導(dǎo)致非常奇怪的錯(cuò)誤，幸運(yùn)的話立刻core dump，不幸的話直到程序運(yùn)行很久以后才莫名其妙的core dump，甚至永遠(yuǎn)不會core dump但是結(jié)果不正確。

如下圖所示，main.cpp中會用到兩個(gè)動態(tài)庫libadd.so，libadd1.so的符號，我們把重點(diǎn)

放在Add函數(shù)的處理上，當(dāng)我們以g++ main.cpp libadd.so libadd1.so編譯時(shí)，程序輸出“Add in add lib”說明Add是用的libadd.so中的符號（add.cpp），當(dāng)我們以g++ main.cpp libadd1.so libadd.so編譯時(shí)。

程序輸出“Add in add1 lib”說明Add是用的libadd1.so中的符號，這時(shí)候問題就大了，調(diào)用方main.cpp中認(rèn)為Add只有兩個(gè)參數(shù)，而add1.cpp中認(rèn)為Add有三個(gè)參數(shù)，程序中如果有這樣的代碼，可以預(yù)見很可能造成巨大的混亂。

具體符號解析我們可以通過LD_DEBUG=all 。/a.out來觀察Add的解析過程，如下圖所示：左邊是對應(yīng)libadd.so在編譯時(shí)放在前面的情況，Add綁定在libadd.so中，右邊對應(yīng)libadd1.so放前面的情況，Add綁定在libadd1.so中。

運(yùn)行時(shí)加載動態(tài)庫：

有了動態(tài)鏈接和共享目標(biāo)文件的加持，Linux提供了一種更加靈活的模塊加載方式：通過提供dlopen，dlsym，dlclose，dlerror幾個(gè)API，可以實(shí)現(xiàn)在運(yùn)行的時(shí)候動態(tài)加載模塊，從而實(shí)現(xiàn)插件的功能。

如下代碼演示了動態(tài)加載Add函數(shù)的過程，add.cpp按照正常編譯“g++ -fPIC –shared –o libadd.so add.cpp”成libadd.so，main.cpp通過“g++ main.cpp -ldl”編譯為a.out。main.cpp中首先通過dlopen接口取得一個(gè)句柄void *handle。

然后通過dlsym從句柄中查找符號Add，找到后將其轉(zhuǎn)化為Add函數(shù)，然后就可以按照正常的函數(shù)使用，最后dlclose關(guān)閉句柄，期間有任何錯(cuò)誤可以通過dlerror來獲取。

問題四：靜態(tài)全局變量與動態(tài)庫導(dǎo)致double free

在全面了解了動態(tài)鏈接相關(guān)知識后，我們來看一個(gè)靜態(tài)全局變量和動態(tài)庫糾結(jié)在一起引發(fā)的問題，代碼如下，foo.cpp中有一個(gè)靜態(tài)全局對象foo_，foo.cpp會編譯成一個(gè)libfoo.a，bar.cpp依賴libfoo.a庫，它本身會編譯成libbar.so，main.cpp既依賴于libfoo.a又依賴libbar.so。

編譯的makefile如下：

運(yùn)行a.out會導(dǎo)致double free的錯(cuò)誤。這是由于在一個(gè)位置上調(diào)用了兩次析構(gòu)函數(shù)造成的。之所以會這樣是因?yàn)殒溄拥臅r(shí)候先鏈接的靜態(tài)庫，將foo_的符號解析為靜態(tài)庫中的全局變量，當(dāng)動態(tài)鏈接libbar.so時(shí)，由于全局已經(jīng)有符號foo_，因此根據(jù)全局符號介入，動態(tài)庫中對foo_的引用會指向靜態(tài)庫中版本，導(dǎo)致最后在同一個(gè)對象上析構(gòu)了兩次。

解決辦法如下：

1. 不使用全局對象

2. 編譯時(shí)候調(diào)換庫的順序，動態(tài)庫放在前面，這樣全局只會有一個(gè)foo_對象

3. 全部使用動態(tài)庫

4. 通過編譯器參數(shù)來控制符號的可見性。

總結(jié)：

通過四個(gè)編譯鏈接中碰到的問題，基本把編譯鏈接的這些事覆蓋了一遍，有了這些基礎(chǔ)，在日常工作中應(yīng)對一般的編譯鏈接問題應(yīng)該可以做到游刃有余。由于篇幅有限，文章省略了大量的細(xì)節(jié)，主要集中在大的框架原理性梳理，如果想進(jìn)一步深挖相關(guān)的細(xì)節(jié)，可參與相關(guān)參考文獻(xiàn)，以及閱讀elf.h相關(guān)的頭文件。

轉(zhuǎn)自：https://my.oschina.net/u/4526289/blog/4651990

編輯：jq