重學計算機組成原理（九）- 動態連結
把對應的不同檔案內的程式碼段，合併到一起，成為最後的可執行檔案
連結的方式，讓我們在寫程式碼的時候做到了“複用”。
同樣的功能程式碼只要寫一次，然後提供給很多不同的程式進行連結就行了。
“連結”其實有點兒像我們日常生活中的標準化、模組化生產。
有一個可以生產標準螺帽的生產線，就可生產很多不同的螺帽。
只要需要螺帽，都可以通過連結的方式，去複製一個出來，放到需要的地方
但是，如果我們有很多個程式都要通過裝載器裝載到記憶體裡面，那裡面連結好的同樣的功能程式碼，也都需要再裝載一遍，再佔一遍記憶體空間。
這就好比，假設每個人都有騎自行車的需要，那我們給每個人都生產一輛自行車帶在身邊，固然大家都有自行車用了，但是馬路上肯定會特別擁擠。
1 連結可以分動、靜，共享執行省記憶體
我們上一節解決程式裝載到記憶體的時候，講了很多方法。說起來，最根本的問題其實就是記憶體空間不夠用。
如果能夠讓同樣功能的程式碼，在不同的程式裡面，不需要各佔一份記憶體空間，那該有多好啊！
就好比，現在馬路上的共享單車，我們並不需要給每個人都造一輛自行車，只要馬路上有這些單車，誰需要的時候，直接通過手機掃碼，都可以解鎖騎行。
這個思路就引入一種新的連結方法，叫作動態連結（Dynamic Link）
相應的，我們之前說的合併程式碼段的方法，就是靜態連結（Static Link）
在動態連結的過程中，我們想要“連結”的，不是儲存在硬碟上的目標檔案程式碼，而是載入到記憶體中的共享庫（Shared Libraries）
這個載入到記憶體中的共享庫會被很多個程式的指令呼叫到。
- 在Windows下，這些共享庫檔案就是.dll檔案，也就是Dynamic-Link Libary（DLL，動態連結庫）
用了“動態連結”的意思 - 在Linux下，這些共享庫檔案就是.so檔案，也就是Shared Object（一般我們也稱之為動態連結庫）。
用了“共享”的意思
正好覆蓋了兩方面的含義。
2 地址無關很重要，相對地址解煩惱
要在程式執行的時候共享程式碼，這些機器碼必須“地址無關”
也就是說，我們編譯出來的共享庫檔案的指令程式碼，是地址無關碼（Position-Independent Code）
換句話說就是，這段程式碼，無論載入在哪個記憶體地址，都能夠正常執行
如果還不明白，我給你舉一個生活中的例子
如果我們有一個騎自行車的程式，要“前進500米，左轉進入天安門廣場，再前進500米”。
它在500米之後要到天安門廣場了，這就是地址相關的。
如果程式是“前進500米，左轉，再前進500米”，無論你在哪裡都可以騎車走這1000米，沒有具體地點的限制，這就是地址無關的。
大部分函式庫其實都可以做到地址無關，因為它們都接受特定的輸入，進行確定的操作，然後給出返回結果就好了。
無論是實現一個向量加法，還是實現一個列印的函式，這些程式碼邏輯和輸入的資料在記憶體裡面的位置並不重要。
而常見的地址相關的程式碼，比如絕對地址程式碼（Absolute Code）、利用重定位表的程式碼等等，都是地址相關的程式碼
回想一下我們之前講過的重定位表。在程式連結的時候，我們就把函式呼叫後要跳轉訪問的地址確定下來了，這意味著，如果這個函式載入到一個不同的記憶體地址，跳轉就會失敗。
對於所有動態連結共享庫的程式來講，雖然我們的共享庫用的都是同一段實體記憶體地址，但是在不同的應用程式裡，它所在的虛擬記憶體地址是不同的。
沒辦法、也不應該要求動態連結同一個共享庫的不同程式，必須把這個共享庫所使用的虛擬記憶體地址變成一致。
如果這樣的話，我們寫的程式就必須明確地知道內部的記憶體地址分配。
那麼問題來了，我們要怎麼樣才能做到，動態共享庫編譯出來的程式碼指令，都是地址無關碼呢？
動態程式碼庫內部的變數和函式呼叫都很容易解決，我們只需要使用相對地址（Relative Address）
各種指令中使用到的記憶體地址，給出的不是一個絕對的地址空間，而是一個相對於當前指令偏移量的記憶體地址
因為 整個共享庫是放在一段連續的虛擬記憶體地址中的，無論裝載到哪一段地址，不同指令之間的相對地址都是不變的。
3 動態連結的解決方案
PLT和GOT
要實現動態連結共享庫，也並不困難，和前面的靜態連結裡的符號表和重定向表類似
拿出一小段程式碼來看一看。
- lib.h
定義了動態連結庫的一個函式 show_me_the_money
- lib.c
包含了lib.h的實際實現
- show_me_poor.c
呼叫了 lib 裡面的函式
- 把 lib.c 編譯成了一個動態連結庫，也就是 .so 檔案
- 最終生成檔案集
在編譯的過程中，指定了一個 -fPIC 的引數
其實就是Position Independent Code意，也就是要把這個編譯成一個地址無關程式碼
然後，我們再通過gcc編譯 show_me_poor 動態連結了 lib.so 的可執行檔案
- 在這些操作都完成了之後，我們把 show_me_poor 這個檔案通過objdump出來看一下。
0000000000400540 <show_me_the_money@plt-0x10>:
400540: ff 35 12 05 20 00 push QWORD PTR [rip+0x200512] # 600a58 <_GLOBAL_OFFSET_TABLE_+0x8>
400546: ff 25 14 05 20 00 jmp QWORD PTR [rip+0x200514] # 600a60 <_GLOBAL_OFFSET_TABLE_+0x10>
40054c: 0f 1f 40 00 nop DWORD PTR [rax+0x0]
0000000000400550 <show_me_the_money@plt>:
400550: ff 25 12 05 20 00 jmp QWORD PTR [rip+0x200512] # 600a68 <_GLOBAL_OFFSET_TABLE_+0x18>
400556: 68 00 00 00 00 push 0x0
40055b: e9 e0 ff ff ff jmp 400540 <_init+0x28>
……
0000000000400676 <main>:
400676: 55 push rbp
400677: 48 89 e5 mov rbp,rsp
40067a: 48 83 ec 10 sub rsp,0x10
40067e: c7 45 fc 05 00 00 00 mov DWORD PTR [rbp-0x4],0x5
400685: 8b 45 fc mov eax,DWORD PTR [rbp-0x4]
400688: 89 c7 mov edi,eax
40068a: e8 c1 fe ff ff call 400550 <show_me_the_money@plt>
40068f: c9 leave
400690: c3 ret
400691: 66 2e 0f 1f 84 00 00 nop WORD PTR cs:[rax+rax*1+0x0]
400698: 00 00 00
40069b: 0f 1f 44 00 00 nop DWORD PTR [rax+rax*1+0x0]我們還是隻關心整個可執行檔案中的一小部分內容
- 在main函式呼叫show_me_the_money的函式的時候，對應的程式碼是這樣的：
這裡後面有一個@plt的關鍵字，代表了我們需要從PLT，也就是程式連結表（Procedure Link Table）裡面找要呼叫的函式。對應的地址呢，則是400580這個地址。
那當我們把目光挪到上面的 400580 這個地址，你又會看到裡面進行了一次跳轉，
- 這個跳轉指定的跳轉地址，你可以在後面的註釋裡面可以看到:
這裡的 GLOBAL_OFFSET_TABLE，就是我接下來要說的全域性偏移表。
在動態連結對應的共享庫，我們在共享庫的data section裡面，儲存了一張全域性偏移表（GOT，Global Offset Table）
雖然共享庫的程式碼部分的實體記憶體是共享的，但是資料部分是各個動態連結它的應用程式裡面各載入一份的。
所有需要引用當前共享庫外部的地址的指令，都會查詢GOT，來找到當前執行程式的虛擬記憶體裡的對應位置
而GOT表裡的資料，則是在我們載入一個個共享庫的時候寫進去的。
不同的程序，呼叫同樣的 lib.so，各自GOT裡面指向最終載入的動態連結庫裡面的虛擬記憶體地址是不同的。
這樣，雖然不同的程式呼叫的同樣的動態庫，各自的記憶體地址是獨立的，呼叫的又都是同一個動態庫，但是不需要去修改動態庫裡面的程式碼所使用的地址，
而是各個程式各自維護好自己的GOT，能夠找到對應的動態庫就好了
GOT表位於共享庫自己的資料段裡
GOT表在記憶體裡和對應的程式碼段位置之間的偏移量，始終是確定的
這樣，共享庫就是地址無關的程式碼，對應的各個程式只需在實體記憶體里加載同一份程式碼
而我們又要通過各個可執行程式在載入時，生成的各不相同的GOT表，找到它需要呼叫到的外部變數和函式的地址
這是一個典型的、不修改程式碼，而是通過修改“地址資料”來進行關聯的辦法
它有點像我們在C語言裡面用函式指標來呼叫對應的函式，並不是通過預先已經確定好的函式名稱來呼叫，而是利用當時它在記憶體裡面的動態地址來呼叫。
4 總結
終於在靜態連結和程式裝載後，利用動態連結把我們的記憶體利用到了極致
同樣功能的程式碼生成的共享庫，我們只要在記憶體裡面保留一份就好了
這樣
- 不僅能夠做到程式碼在開發階段的複用
- 也能做到程式碼在執行階段的複用。
實際上，在進行Linux程式開發，一直會用到各種各樣的動態連結庫。
C語言的標準庫就在1MB以上。
撰寫任何一個程式可能都需要用到這個庫，常見的Linux伺服器裡，/usr/bin下面就有上千個可執行檔案。
如果每一個都把標準庫靜態連結進來的，幾GB乃至幾十GB的磁碟空間一下子就用出去了。如果我們服務端的多程序應用要開上千個程序，幾GB的記憶體空間也會一下子就用出去了。這個問題在過去計算機的記憶體較少的時候更加顯著。
通過動態連結這個方式，可以說_徹底解決了這個問題_。
就像共享單車一樣，如果仔細經營，是一個很有社會價值的事情，但是如果粗暴地把它變成無限制地複製生產，給每個人造一輛，只會在系統內製造大量無用的垃圾。
已經把程式怎麼從原始碼變成指令、資料，並裝載到記憶體裡面，由CPU一條條執行下去的過程講完了。希望你能有所收穫，對於一個程式是怎麼跑起來的，有了一個初步的認識。
5 推薦閱讀
想要更加深入地瞭解動態連結，推薦你可以讀一讀《程式設計師的自我修養：連結、裝載和庫》的第7章
裡面深入地講解了，動態連結里程序內的資料佈局和對應資料的載入關係。
參考
- 深入淺出計算機組成原理