《程序员的自我修养》第4章---静态链接
第4章 靜態(tài)鏈接
4.1 空間和地址分配：
a.c :
extern int shared;int main() {int a = 100;swap(&a, &shared); }b.c :
int shared = 1; void swap(int* a, int* b) {*a ^= *b ^= *a ^= *b; }對于鏈接器來說，整個鏈接過程，它的工作就是將幾個輸入的目標(biāo)文件加工、合并成一個輸出的可執(zhí)行文件。
例如將輸入的 a.o 和 b.o 文件合并成可執(zhí)行文件 ab。
鏈接器的合并方式：
4.1.1 按序疊加：
pass
浪費(fèi)空間。
4.1.2 相似段合并：
將所有輸入文件的 .text 合并到輸出文件的 .text段，.data段合并到 .data段，以此類推，等等。
“鏈接器為目標(biāo)文件分配地址和空間” 這句話中的 “地址和空間” 其實(shí)有兩個含義：
當(dāng)我們談到空間分配時，只關(guān)注虛擬地址空間的分配。
“相似段合并”的空間分配方法采用 “兩步鏈接”（Two-pass Linking）的方法：
在Linux下，ELF可執(zhí)行文件默認(rèn)從地址 0x08048000 開始分配（32位操作系統(tǒng)）。
4.2 符號解析與重定位：
4.2.2 重定位表：
鏈接器如何知道哪些指令需要被調(diào)整？
借助于 ELF文件中的 “重定位表”（Relocation Table）。
重定位表在ELF文件中一般是一個或多個段，例如，如果 .data段中有需要被重定位的符號，那么ELF文件中就會有一個相對應(yīng)的 .rel.text段，用于保存 .data段中需要被重定位的地方。
使用 objdump -r 命令可以查看目標(biāo)文件中的所有重定位入口：
objdump -r, --reloc Display the relocation entries in the file//查看目標(biāo)文件中的所有重定位入口例如，查看 a.o 目標(biāo)文件中的重定位入口信息：
[linux] objdump -r a.oa.o： 文件格式 elf64-x86-64RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 0000000000000014 R_X86_64_32 shared 0000000000000021 R_X86_64_PC32 swap-0x0000000000000004RELOCATION RECORDS FOR [.eh_frame]: OFFSET TYPE VALUE 0000000000000020 R_X86_64_PC32 .text查看 b.o 目標(biāo)文件中的重定位入口信息：
[linux] objdump -r b.ob.o： 文件格式 elf64-x86-64RELOCATION RECORDS FOR [.eh_frame]: OFFSET TYPE VALUE 0000000000000020 R_X86_64_PC32 .text可以看到 a.o 中有兩個重定位入口，重定位入口 偏移（Offset） 表示該入口在要被重定位的段中的位置。
4.4 C++相關(guān)問題：
C++的一些語言特性使之必須由編譯器和鏈接器共同支持才能完成，最主要的有兩個方面：
4.4.1 重復(fù)代碼消除：
C++編譯器會產(chǎn)生重復(fù)代碼的場景： 模板、外部內(nèi)聯(lián)函數(shù)、虛函數(shù)表， 這些都有可能在不同的編譯單元里產(chǎn)生相同的代碼。
模板在本質(zhì)上來講很像宏（宏也是符號的替代）,
例如一個模板 template class A {}; 在頭文件 header.h 中，
在 a.c 中實(shí)例化 A a, 在 b.c 中實(shí)例化為 A b，這會導(dǎo)致在 a.o 與 b.o 的目標(biāo)文件中存在重復(fù)的代碼，
“當(dāng)模板在一個編譯單元里被實(shí)例化時，它并不知道自己是否在別的單元也被實(shí)例化了。所以當(dāng)一個模板在多個編譯單元同時實(shí)例化成相同的類型的時候，必然會生成重復(fù)的代碼。”
如果不管這些，直接將重復(fù)的代碼都保留下來，會造成下面幾個問題：
一種解決模板產(chǎn)生重復(fù)代碼的方法是：
編譯器 ----> 遇到template類模板或函數(shù)模板時，將每個模板的實(shí)例代碼都單獨(dú)存放在一個段里（目標(biāo)文件中），在目標(biāo)文件中以相同的規(guī)則取名 ----> 鏈接器 ----> 在最終的鏈接階段，將同類型的模板實(shí)例的段進(jìn)行合并，然后生成可執(zhí)行文件。
例如有一個模板函數(shù) add()， 某個編譯單元.c文件中以 int 和float 類型實(shí)例化了該模板函數(shù)，那么該編譯單元的目標(biāo)文件中就包含了兩個該模板實(shí)例的段，假設(shè)名為：
.temp.add , .temp.add
這樣，當(dāng)別編譯單元也以 int 或 float 類型實(shí)例化 該模板函數(shù)后，也會生成相同的名字，
這樣鏈接器在最終鏈接的時候就可以區(qū)分這些相同的模板實(shí)例段，然后將它們合并入最后的代碼段。
這種做法目前被主流編譯器所采用，包括 GCC 和 Visual C++。
對于 外部內(nèi)聯(lián)函數(shù) 和 虛函數(shù)表，消除重復(fù)代碼的方法也與 模板 的做法類似：
例如對于一個有虛函數(shù)的類，有一個與之對應(yīng)的虛函數(shù)表，編譯器會在用到該類的多個編譯單元生成虛函數(shù)表，造成代碼重復(fù)，默認(rèn)構(gòu)造函數(shù)、默認(rèn)拷貝構(gòu)造函數(shù)、賦值構(gòu)造運(yùn)算符等也有類似的問題，解決方法與類模板一樣： 編譯器在 編譯階段 在目標(biāo)文件.o中為虛函數(shù)表生成單獨(dú)的段，鏈接器在 鏈接階段 合并不同目標(biāo)文件中的同名的段，最終生成可執(zhí)行文件。
特殊情況是：
不同的編譯單元使用不同的編譯器，然后將生成的多個目標(biāo)文件.o 使用鏈接器進(jìn)行合并，
此時不同的編譯單元中的段的名字相同，但內(nèi)容由于編譯器版本或者編譯選項(xiàng)的不同，導(dǎo)致同一個函數(shù)編譯出來的實(shí)際代碼有所不同，此時：
鏈接器會做出一個選擇，隨機(jī)選取一個版本進(jìn)行鏈接，并拋出一個警告消息。
函數(shù)鏈接級別：
Visual C++編譯器提供一個 編譯選項(xiàng) 叫 “函數(shù)級別鏈接”，針對程序和庫較大時，成千上百個函數(shù)或變量，有些函數(shù)或變量可能并沒有被用到，此時就沒必要將其鏈接進(jìn)來，此編譯選項(xiàng)允許當(dāng)鏈接器用到某個函數(shù)時，再將其合并到輸出文件中，以達(dá)到節(jié)省空間的目的。缺點(diǎn)是會減慢編譯和鏈接過程。
4.4.2 全局構(gòu)造與析構(gòu)：
一個C/C++程序 是從main開始執(zhí)行，隨著main函數(shù)的結(jié)束而結(jié)束。
在main函數(shù)開始調(diào)用之前，操作系統(tǒng)需要先初始化進(jìn)程執(zhí)行環(huán)境，包括：
堆內(nèi)存分配初始化、線程子系統(tǒng)等。 C++全局對象的構(gòu)造函數(shù)也在這一時期被執(zhí)行。
C++全局對象 的構(gòu)造函數(shù)在 main 之前被執(zhí)行，C++全局對象 的析構(gòu)函數(shù)在 main之后被執(zhí)行。
Linux系統(tǒng)下一般程序的入口是 _start 函數(shù)，這個函數(shù)是Linux系統(tǒng)庫（Glibc）的一部分。
4.4.3 C++ 與 ABI：
ABI = Application Binary Interface，與API（Application Programming Interface）類似，只是在不通層面的接口。
如果要讓不同的編譯器產(chǎn)生的目標(biāo)文件能夠兼容鏈接，要考慮它們的ABI是否兼容。
4.5 靜態(tài)庫鏈接：
程序之所以有用，因?yàn)樗鼤休斎胼敵?#xff0c;這些輸入輸出的對象可以是數(shù)據(jù)，可以是人，也可以是另外一個程序，還可以是另一臺計(jì)算機(jī)，一個沒有輸入輸出的程序沒有任何意義。
但是一個程序如何做到輸入輸出呢？
最簡單的辦法是使用操作系統(tǒng)提供的API（應(yīng)用程序編程接口，Application Programming Interface）。
程序如何調(diào)用操作系統(tǒng)提供的API呢？
一般情況下，一種語言的開發(fā)環(huán)境虎附帶有 “語言庫”（Language Library），這些庫就是對操作系統(tǒng)API的包裝。
例如經(jīng)典的C語言的“hello world”程序，它使用 C語言標(biāo)準(zhǔn)庫 的 printf函數(shù)來輸出一個字符串，在Linux下，它是對 write 系統(tǒng)調(diào)用的封裝，在Windows下，它是對 WriteConsole 系統(tǒng)API的封裝。
如何組織C運(yùn)行庫：
在一個C運(yùn)行庫中，包含了很多跟系統(tǒng)功能相關(guān)的代碼，例如輸入輸出、文件操作、時間日期、內(nèi)存管理等等，glibc中由成百上千的C語言源程序文件組成，也就是編譯后會產(chǎn)生相同數(shù)量的目標(biāo)文件。
如果把這些零散的目標(biāo)文件直接提供給庫的使用者，則會造成傳輸、管理的不便，因此，通常使用 ar 工具將這些目標(biāo)進(jìn)行壓縮打包，生成 libc.a 靜態(tài)庫文件。
可以使用ar工具查看靜態(tài)庫文件中包含哪些目標(biāo)文件：
(libc.a中共包含了大概 1400個目標(biāo)文件)
其實(shí)一個靜態(tài)庫可以簡單看成 一組目標(biāo)文件的集合，即很多目標(biāo)文件經(jīng)過壓縮打包后形成的一個文件。
ar 壓縮程序 ----> 多個 .o 文件 ----> 合成 .a 庫文件
一個鏈接過程，就是不斷的尋找程序中的符號所在的目標(biāo)文件，然后將其加入進(jìn)來，如果靠人工這將是一個很復(fù)雜的過程。
例如：
hello.c ----> printf.o ----> stdout.o, vprintf.o ----> …
（hello.c中包含printf()函數(shù)，在printf.o目標(biāo)文件中，printf.o中又有stdout和vprintf兩個符號，以此類推，找出所有的依賴的符號所在的目標(biāo)文件。。）
“幸好ld鏈接器會處理這一切繁瑣的事務(wù)，自動尋找所有需要的符號及它們所在的目標(biāo)文件，將這些目標(biāo)文件從 “l(fā)ibc.a”中 “解壓”出來，最終將它們鏈接在一起稱為一個可執(zhí)行文件。”
然而僅僅是將.a庫中的所有依賴目標(biāo)文件找到并鏈接仍是不夠的，后面再繼續(xù)介紹。
collect2：
collect2 可以看作是ld鏈接器的一個包裝，它會調(diào)用ld鏈接器來完成對目標(biāo)文件的鏈接，然后再對鏈接結(jié)果進(jìn)行一些處理，主要是收集所有與程序初始化相關(guān)的信息并且構(gòu)造初始化的結(jié)構(gòu)。
Q&A：
Q： 為什么靜態(tài)庫里面一個目標(biāo)文件只包含一個函數(shù)？
A： 鏈接器在鏈接靜態(tài)庫的時候是以目標(biāo)文件為單位的。當(dāng)引用了靜態(tài)庫中的printf()函數(shù)時，鏈接器就會把printf()函數(shù)所在的目標(biāo)文件鏈接進(jìn)來。
如果很多函數(shù)都放在同一個目標(biāo)文件中，就可能會造成其他沒用的函數(shù)都被一起鏈接進(jìn)了輸出結(jié)果中。
由于運(yùn)行庫有成百上千個函數(shù)，數(shù)量非常龐大，每個函數(shù)獨(dú)立的放在一個目標(biāo)文件中可以盡量減少空間的浪費(fèi)，那些沒有被用到的目標(biāo)文件（函數(shù)）就不要鏈接到最終的輸出文件中。
9. C/C++ 運(yùn)行庫、靜態(tài)庫、動態(tài)庫 的區(qū)別與聯(lián)系：
https://blog.csdn.net/ithzhang/article/details/20160009
9.1 從C和C++運(yùn)行庫說起：
為了提高C語言的開發(fā)效率，C標(biāo)準(zhǔn)定義了一系列常用的函數(shù)，稱為C庫函數(shù)。
C標(biāo)準(zhǔn)僅僅定義了函數(shù)原型，并沒有提供實(shí)現(xiàn)。因此這個任務(wù)留給了各個支持C語言標(biāo)準(zhǔn)的編譯器。
每個編譯器通常實(shí)現(xiàn)了標(biāo)準(zhǔn)C的超集，稱為 “C運(yùn)行時庫”（C Run Time Library），簡稱 CRT。
對于VC++編譯器來說，它提供的CRT庫支持C標(biāo)準(zhǔn)定義的標(biāo)準(zhǔn)C函數(shù)，同是也有一些專門針對Windows系統(tǒng)特別設(shè)計(jì)的函數(shù)（對于Linux系統(tǒng)、GCC編譯器也是一樣的道理）。
可以簡單理解：
C標(biāo)準(zhǔn)庫 + 編譯器自定義的針對具體操作提供的專門函數(shù) = C運(yùn)行時庫（CRT）
與C語言類似，C++也定義了自己的標(biāo)準(zhǔn)，同時提供相關(guān)支持庫，我們將它稱為C++運(yùn)行時庫或C++標(biāo)準(zhǔn)庫。
由于C++對C的兼容性，C++標(biāo)準(zhǔn)庫包括了C標(biāo)準(zhǔn)庫，除此之外還包括 IO流、標(biāo)準(zhǔn)模板庫STL。
9.2 VC++在何處實(shí)現(xiàn)C和C++運(yùn)行庫：
VC++完美支持C和C++標(biāo)準(zhǔn)，即按照C和C++的標(biāo)準(zhǔn)中定義的函數(shù)原型實(shí)現(xiàn)了上述運(yùn)行時庫。
為了方便有不同需求的用戶的使用，VC++分別實(shí)現(xiàn)了 動態(tài)鏈接庫DLL版本 和 靜態(tài)庫LIB版本。
同時為了支持程序調(diào)試且不影響程序的性能，又分別提供了對應(yīng)的調(diào)試版本。
對于C運(yùn)行時庫 CRT、VC6.0、VC2005、VC2008、VC2010等，均提供了 DLL版本 和 LIB版本（供用戶根據(jù)實(shí)際需要選擇DLL方式還是LIB方式的庫）。
9.3 動態(tài)版（DLL）和靜態(tài)版（LIB）C和C++運(yùn)行庫的優(yōu)缺點(diǎn)：
動態(tài)鏈接庫： DLL（Dynamic Linking Library），Windows下的 .dll 和 Linux下的 .so 文件；
靜態(tài)鏈接庫： Static Linking Library， Windows下的 .lib 和 Linux下的 .a 文件。
因?yàn)殪o態(tài)版必須把C和C++運(yùn)行庫復(fù)制到目標(biāo)程序(.o)中，所以產(chǎn)生的可執(zhí)行文件會比較大。
使用DLL版的C和C++運(yùn)行庫，程序砸運(yùn)行時動態(tài)的加載對應(yīng)的DLL，程序體積變小，但一個很大的問題就是一旦找不到對應(yīng)的DLL，程序?qū)o法運(yùn)行。
靜態(tài)庫的鏈接方法：
gcc main.c -static -o main -L. -lstatic動態(tài)庫的鏈接方法：
gcc main.c -o main -L. -lshared總結(jié)
以上是生活随笔為你收集整理的《程序员的自我修养》第4章---静态链接的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 将汉字转换成全拼或者首字母（Oracle
- 下一篇： eCGUI-QQ群