一加Ace2 Pro真機揭曉 鈦空灰配色質感拉滿
終于，在經過了幾波預熱之后，一加Ace2 Pro的外觀真機圖在網上出現了。還是博主數碼閑聊站曝光的，這次的外觀設計還是延續了一加11的方案，只是細節上有了調整，例如新加入了鈦空灰
大家好，我是小風哥，今天簡單聊聊動態鏈接庫的實現原理。
假設有這樣兩段代碼，第一段代碼定義了一個全量變量a以及函數foo，函數foo中引用了下一段代碼中定義的全局變量b。
圖片
第二段代碼定義了全局變量b以及main函數，同時在main函數中調用了第一個模塊中定義的函數foo。
接下來編譯器出場，編譯器會把這個兩個源文件編譯成對應的目標文件。
目標文件中主要有兩部分，代碼段和數據段，這兩部分里面分別包含什么內容呢？
我們定義的全局變量會被放到數據段，代碼被編譯生成的二進制指令會被放到代碼段，第二個目標文件也一樣。
圖片
注意看第一段代碼，這里引用了一個其它模塊定義的全局變量b，這一信息記錄在第一個目標文件，第二段代碼引用了其它模塊定義的函數foo，這一信息記錄在第二個目標文件。
注意看第一段代碼，這里定一個全局變量a和函數foo，我們記錄下來，第二段代碼定義了全局變量b和函數main，同樣記錄下來。
圖片
接著我們開始一個叫做連連看的游戲。
第一個模塊引用了變量b，變量b的定義可以在第二個模塊找到。
第二個模塊引用了函數foo，foo的定義可以在第一個模塊找到。
這個過程叫做符號解析。
圖片
這里看到的引用以及定義的符號保存在所謂的符號表中。
而如果第二個模塊引用了一個叫做bar的變量，鏈接器翻遍所有其它模塊都沒找到bar這個符號的定義，而只找到了一個叫做foo的定義，這時鏈接器就會報一個叫做符合未定義的錯誤，這個錯誤寫c/c++的程序員一定不陌生。
圖片
接下來鏈接器會把數據段合并到一起，代碼段合并到一起并確定符號的內存地址，這個過程叫做重定位。
了解了這些就可以開始講動態庫的實現原理了，動態庫又叫做共享庫，我們的問題是，動態庫是怎么實現可以被程序之間共享的呢？
假設現在有兩個運行的程序和一個動態庫liba. so，動態庫中定了一個全局變量a，第一個程序把變量a修改為了10。
圖片
然后第二個程序開始運行，第二個程序也使用該動態庫，然后把全局變量a修改為了20。
圖片
這是第一個程序運行一段時間后決定打印變量a，這時你會驚訝的發現變量a從10變成了20，但是為什么。
原因就是這兩個程序共享了同一個數據段，所以一個程序對數據的修改對另一人程序是可見的，因此動態庫中的數據段不能共享，每個程序需要有自己的數據段。
現在數據的問題解決了，我們來看函數。
假設動態庫liba.so需要引用外部定義的foo函數，由于程序1和程序2都使用了該動態庫，因此必須定義出foo函數。
我們知道函數調用最終會被編譯器翻譯成call機器指令后跟函數地址。
圖片
接下來我們需要解析出foo函數的地址到底是什么，這就是剛才我們提到的重定位，只不過動態庫將這一過程推遲到了運行時。
由于程序1的foo函數位于內存地址0x123這個位置，因此鏈接器將call指令后的地址修正為0x123。
這時CPU執行這條call指令就能正確的跳轉到第一個程序的foo函數。
圖片
而第二個程序的foo函數為內存地址0x456這個位置，接下來第二個程序開始運行，CPU開始執行foo函數，由于第二個程序的foo函數在0x456，因此我們希望CPU能跳轉到這里，但由于動態庫中call指令后跟的是0x123這個內存地址，因此CPU執行foo函數時依然會跳轉到第一個程序的foo函數。
圖片
這時系統就出現了錯誤。
問題出在了哪里呢？
主要是call這條機器指令，這條指令后跟了一個絕對的內存地址，而不要忘了，這條指令或者說動態庫是要被各個程序共享的，顯然我們不能直接使用絕對地址。
該怎么辦呢？
計算機中所有問題都可以通過增加一個中間層來解決。
圖片
這樣我們就摒棄了直接調用，而采用間接調用。
而我們這里對函數的討論對于全局變量的應用也是一樣的道理，全局變量的使用也存在同樣的問題，只不過是從函數調用變成了內存讀寫，解決問題的方法一樣，我們從直接應用改為間接引用。
接下來我們依然以函數調用為例來講解。
那么這個中間層到底是什么呢？
答案就是got。
還記得剛才提到的每個程序都有自己的數據區嗎，這個got段就屬于數據區的一部分。
圖片
got中有什么呢？got中記錄了引用的全局變量或者函數的地址，在程序運行時鏈接器會找到foo的內存地址，然后填到got表中，這樣通過查got表我們就能知道函數foo的內存地址了。
接下來的問題就是當CPU調用foo函數時怎么才能知道got表在哪里呢？
注意剛提到每個程序都有自己的數據區，實際上對于動態庫來說也有自己的代碼區。
我們現在只需要知道每個程序運行在自己的地址空間中，這些地址空間最終會被映射到真正的物理內存，動態庫中的數據區會被映射到不同的內存區域，但代碼段會被映射到同一段物理內存中，從而實現共享的目的。
圖片
接下來我們重點看進程地址空間中的動態庫布局。
注意看，動態庫的數據區和代碼區總是相鄰的，也就是代碼區和got段的相對位置總是不變的，而不管動態庫被放到了哪個位置。
多個程序也一樣，也就是代碼區和數據區的相對位置總是固定的，這個相對位置在編譯時編譯器就能確定。
圖片
現在foo會被編譯成call指令，而程序在加載時鏈接器會向got段中寫入foo的內存地址，顯然兩個程序的foo地址是不一樣的。
接下來CPU開始執行第一個程序的call指令，此時CPU會做一個相對跳轉，這個跳轉距離是編譯器確定的，CPU會跳轉到got表，然后查找foo的地址發現是0x123，然后開始執行0x123這個位置的函數。
圖片
而如果CPU執行第二個程序中的foo函數，那么CPU同樣會進行相對跳轉，這不過這次跳轉到的是第二個程序的got表，然后發現foo的地址是0x456，然后開始執行第二個程序中的foo函數。
圖片
這樣我們就實現了執行同一個指令但卻會跳轉到不同地址的目的，從而在不改動動態庫代碼的前提先實現共享。
而如果一個動態庫中引用了很多外部函數會怎么樣呢？
這樣程序在啟動時鏈接器不得不對所有函數進行重定位，因此會拖慢程序啟動速度。
而我們知道一個程序中不是所有的函數都會被調用到，經常調用的都是少數幾個函數，為了利用這一點編譯鏈接系統使用procedure linkage table, plt來推遲重定位這個過程，也就是程序在啟動時不進行函數重定位，而是推遲到真正調用函數時，沒用調用過的函數根本就不進行重定位，從而加快程序啟動速度。
從這個一過程我們可以看到動態庫的這種間接調用實際上會對程序性能有一定影響，但相對于動態庫帶來的好處與便捷，這點影響可以忽略不計。
這樣，不管動態庫被加載到內存的哪個位置都能正確被各個程序共享。
動態庫的這個特性被稱之為位置無關代碼，簡稱position-independent code, pic，這就是為什么你在編譯生成動態庫時要加上pic編譯選項的原因。
圖片
希望這篇對大家理解動態庫有幫助。
本文鏈接：http://www.www897cc.com/showinfo-26-92467-0.html動態鏈接庫的實現原理是什么？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
下一篇： 三分鐘帶你秒懂CAS實現機制
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號