問題描述

昨天下午，旁邊的同事在學(xué)習(xí)Linux系統(tǒng)中的虛擬地址映射（經(jīng)典書籍《程序員的自我修養(yǎng)－鏈接、裝載與庫》），在看到6．4章節(jié)的時(shí)候，對于一個(gè)可執(zhí)行的ELF文件中，虛擬地址的值百思不得其解！

例如下面這段C代碼：

首先編譯出32位的可執(zhí)行程序（為了避開一些與主題無關(guān)的干擾因素，采用了靜態(tài)鏈接）：

gcc －m32 －static test．c －o test

編譯得到ELF格式的可執(zhí)行文件：test。

這個(gè)時(shí)候，使用readelf工具來查看這個(gè)可執(zhí)行文件中的段信息（segment）：

上圖中的紅色矩形框中，第二個(gè)段的地址為什么是 0x080e＿9f5c？

這篇文章主要根據(jù)書中的解釋，來具體的分析這個(gè)值的來龍去脈。

ELF 文件格式

在Linux系統(tǒng)中，有4種類型的文件都是ELF格式，包括：目標(biāo)文件，可執(zhí)行文件，動(dòng)態(tài)鏈接庫文件、核心轉(zhuǎn)儲(chǔ)文件。

如果想系統(tǒng)掌握Linux系統(tǒng)中的底層知識(shí)，研究ELF的格式是避免不了的事情。

很久之前總結(jié)過這篇文章：《Linux系統(tǒng)中編譯、鏈接的基石－ELF文件：扒開它的層層外衣，從字節(jié)碼的粒度來探索》，里面詳細(xì)總結(jié)了ELF文件的內(nèi)部結(jié)構(gòu)。

這里就不再贅述了，只要記住2點(diǎn)：

1.從編譯器的角度看，ELF 文件是由很多的節(jié)（Section）組成的；

2.從程序加載器的角度看，ELF 文件是又很多的段（Segment）組成的；

其實(shí)它倆沒有本質(zhì)區(qū)別，只不過是鏈接器在鏈接階段，把不同目標(biāo)文件中相同的section組織在一起，形成一個(gè) segment。

對于剛才編譯出的test可執(zhí)行文件，其加載視圖如下：

可以看到該文件一共有5個(gè)段（segment），前2個(gè)需要LOAD到內(nèi)存的段，它們屬性分別是：讀、執(zhí)行（R E） 和 讀、寫（RW），它們分別是代碼段和數(shù)據(jù)段。

綠色的箭頭反映出：代碼段中包含了很多的 section；黃色的箭頭反映出數(shù)據(jù)段也包含了很多的 section。

地址轉(zhuǎn)換和內(nèi)存映射

從地址轉(zhuǎn)換的角度來看：

Linux 系統(tǒng)中CPU中使用的都是虛擬地址，該虛擬地址在尋址的時(shí)候，需要經(jīng)過MMU地址轉(zhuǎn)換，得到實(shí)際的物理地址，然后才能在物理內(nèi)存中讀取指令，或者讀取、寫入數(shù)據(jù)。

在現(xiàn)代操作系統(tǒng)中，MMU地址轉(zhuǎn)換單元基本上都是通過頁表來進(jìn)行地址轉(zhuǎn)換的：

當(dāng)然了，有些系統(tǒng)是兩級轉(zhuǎn)換（頁目錄、頁表），有些系統(tǒng)是三級或者四級頁表。

從內(nèi)存映射的角度來看：

操作系統(tǒng)在把一個(gè)可執(zhí)行程序加載到系統(tǒng)中時(shí)，把ELF文件中每個(gè)段的內(nèi)容讀取到物理內(nèi)存中，然后把這個(gè)物理內(nèi)存映射到該段對應(yīng)的虛擬地址上（VirtAddr）。

假設(shè)一個(gè)可執(zhí)行程序中的代碼段長度是1．2K字節(jié)， 數(shù)據(jù)段長度是1．3K字節(jié)。

操作系統(tǒng)在把它倆讀取到內(nèi)存中時(shí)，需要 2 個(gè)物理內(nèi)存頁來分別存儲(chǔ)它們（每 1 個(gè)物理頁的長度是4K）：

雖然每一個(gè)物理內(nèi)存頁的大小是 4K，但是代碼段和數(shù)據(jù)段實(shí)際上只使用了每個(gè)頁面剛開始的一段空間。

當(dāng)CPU中需要讀取物理內(nèi)存上代碼段中的指令時(shí)，使用的虛擬地址是 0x0000＿1000 ～ 0x0000＿1000 ＋ 1．2K這個(gè)區(qū)間的地址，MMU單元經(jīng)過頁表轉(zhuǎn)換之后，就會(huì)得到這個(gè)存放著代碼段的物理頁的物理地址。

數(shù)據(jù)段的尋址方式也是如此：當(dāng)CPU中需要讀寫物理內(nèi)存上數(shù)據(jù)段中的數(shù)據(jù)時(shí)，使用的虛擬地址是 0x0000＿2000 ～ 0x0000＿2000 ＋ 1．3K這個(gè)區(qū)間的地址。

MMU單元經(jīng)過頁表轉(zhuǎn)換之后，就會(huì)得到存放著數(shù)據(jù)段的物理頁的物理地址。

可以看出在這樣的安排下，每一個(gè)段的虛擬地址，都是按照4K（0x1000）對齊的。

如果操作系統(tǒng)都是這樣簡單映射的話，那么事情就簡單多了。

如果按照這樣的安排，來分析一下文章開頭的 test 可執(zhí)行程序中的虛擬地址安排：

1.代碼段安排的開始虛擬地址是 0x0804＿8000，這是 4K 對齊的；

2.代碼段的結(jié)束虛擬地址就應(yīng)該是 0x0804＿8000 ＋ 0xa0725 ＝ 0x080e＿8725；

3.那么數(shù)據(jù)段的開始地址就可以安排在 0x080e＿8725 之后的下一個(gè) 4K 對齊的邊界地址，即：0x080e＿9000。

但是這樣的地址安排，嚴(yán)重浪費(fèi)了物理內(nèi)存空間！

1．2K 字節(jié)的代碼段加上1．3K字節(jié)的數(shù)據(jù)段，本來只需要1個(gè)物理頁就夠了（4KB），但是這里卻消耗掉2個(gè)物理頁（8KB）。

為了減少物理內(nèi)存的浪費(fèi)，Linux操作系統(tǒng)就采用了一些巧妙的辦法來減少物理內(nèi)存的浪費(fèi)，那就是： 把文件中接壤部分的代碼段和數(shù)據(jù)段，讀取到同一個(gè)物理內(nèi)存頁中，然后在虛擬地址空間中映射兩次，詳述如下。

Linux 中的內(nèi)存重復(fù)映射

先來看一下test文件的結(jié)構(gòu)：

代碼段在文件中的開始位置是：0x00000，長度是 0xa0725。

數(shù)據(jù)段的開始位置是：0xa0f5c，長度是0x1024。

可以看到它倆之間有一個(gè)空白區(qū)間，長度是： 0xa0f5c － 0xa0725 ＝ 0x837（十進(jìn)制：2103字節(jié)）。

由于操作系統(tǒng)在把test文件讀取到物理內(nèi)存的時(shí)候，從文件開始代碼段的0x00000地址開始讀取，按照4KB為一個(gè)單位存放到一個(gè)物理頁中。

1.文件中代碼段的 0x00000 ～ 0x00FFF 讀取到一個(gè)物理頁中；

2.文件中代碼段的 0x01000 ～ 0x01FFF 讀取到物理頁中；

3.下面的內(nèi)容都是如此分割、復(fù)制；

也就是說：相當(dāng)于把test文件從開始位置，按照4KB為一個(gè)單位進(jìn)行＂切割＂，然后復(fù)制到不同的物理內(nèi)存頁中，如下所示：

注意：這些物理頁的地址很可能是不連續(xù)的。

這里有意思的是：代碼段與數(shù)據(jù)段接壤的這個(gè)4KB的空間，它的開始地址是0xA0000，結(jié)束地址是0xA0FFF，被復(fù)制到物理內(nèi)存中最上面的橙色物理頁中。

再來看一下代碼段的虛擬地址：在執(zhí)行g(shù)cc指令的的時(shí)候，鏈接器把代碼段的虛擬地址安排在0x0804＿8000處：

也就是說：當(dāng)CPU中（或者說程序代碼中），使用0x0804＿8000 ～ 0x0804＿7FFF 這個(gè)區(qū)間的地址時(shí)，經(jīng)過地址映射，就會(huì)找到物理內(nèi)存中淺綠色的物理頁，而這個(gè)物理頁也對應(yīng)著test可執(zhí)行文件開始的第一個(gè)4KB的空間。

而且，從虛擬地址的角度看，它的地址都是連續(xù)的，對應(yīng)著test文件中連續(xù)的內(nèi)容，這也是虛擬地址映射的本質(zhì)。

把代碼段的開始位置安排在 0x0804＿8000 地址，這是 Linux 操作系統(tǒng)確定的。

那么考慮一下：代碼段的最后一部分指令相應(yīng)的4K頁面，其對應(yīng)的開始虛擬地址是多少呢？

上圖中已經(jīng)標(biāo)記出來了，就是虛擬地址中橙色部分：0x080e＿8000，計(jì)算如下：

通過代碼段的開始地址0x0804＿8000，再加上代碼段在內(nèi)存中的長度0xa0725，結(jié)果就是 0x080e＿8725。

按照4K （0x1000）對齊之后，最后一個(gè)虛擬頁就應(yīng)該是0x080e＿8000。

也就是說：虛擬地址中0x080e＿8000 ～ 0x080e＿8724 這個(gè)區(qū)間就對應(yīng)著test文件中代碼段的最后一部分指令（0x725個(gè)字節(jié)）。

此外，上圖中最右側(cè)：test文件結(jié)構(gòu)中的2個(gè)紅色地址：0xA0000， 0xA1000，是如何計(jì)算得到的？

代碼段的長度是 0xA0725，按照4K為一個(gè)單位來進(jìn)行分割，也就是把0xA0725對0x1000進(jìn)行整除，就得到這個(gè)4KB的開始地址0xA0000。

同理，下一個(gè)4KB的開始地址就是0xA1000。

把文件中這部分4K的數(shù)據(jù)（包括：一部分代碼段內(nèi)容 ＋ 0x837 字節(jié)空洞 ＋ 一部分?jǐn)?shù)據(jù)段內(nèi)容），復(fù)制到上圖中物理內(nèi)存中最上面的橙色物理頁中。

又因?yàn)樘摂M地址空間中，0x080E＿8000開始的這個(gè)4KB空間映射到這個(gè)物理頁中，所以：在這個(gè)虛擬地址空間中，也有一個(gè)0x837字節(jié)的空洞，如下所示：

空洞的下方，是代碼段的指令；空洞的上方，是數(shù)據(jù)段的數(shù)據(jù)。

現(xiàn)在，這個(gè)物理頁中即存放了代碼，又存放了數(shù)據(jù)。

那么CPU中在查找部分的代碼和數(shù)據(jù)的時(shí)候，必須都能夠找得到才行！

對于代碼段比較好理解：從這個(gè)物理頁開始的前0x725個(gè)字節(jié)是有效的，從虛擬地址的角度看，就是從0x080e＿8000開始的前0x725個(gè)字節(jié)是有效的。

因此，對于這部分代碼的尋址，使用的虛擬地址處于0x080e＿8000 ～ 0x080e＿8724這個(gè)區(qū)間中。

那么數(shù)據(jù)段呢？

重點(diǎn)來了：Linux系統(tǒng)把虛擬地址空間 0x080e＿9000 ～ 0x080e＿9FFF 也映射到圖中物理內(nèi)存中最上面的橙色物理頁上！

如下所示：

因?yàn)槲锢眄撝校菑?x837個(gè)字節(jié)空洞的上面開始，才是真正的數(shù)據(jù)段內(nèi)容，那么相應(yīng)的： 虛擬地址0x080e＿9000 ～ 0x080e＿9FFF空間中，0x837字節(jié)上面的內(nèi)容才是數(shù)據(jù)段內(nèi)容。

那么在虛擬地址空間中，這個(gè)數(shù)據(jù)段的開始地址應(yīng)該是多少呢？

只要計(jì)算出0x837字節(jié)空洞的上方，距離這個(gè)4K頁面開始地址的偏移量就可以了，然后再加上這個(gè)4K頁面的起始地址 0x080E＿9000，就得到了數(shù)據(jù)段的開始地址（虛擬地址）。

因?yàn)樘摂M地址、物理地址、test文件中，都是按照4K的單位進(jìn)行劃分的，因此這個(gè)偏移量就等于：test文件中數(shù)據(jù)段的開始地址（0xA0F5C） 距離 這個(gè)頁面的開始地址（0xA0000） 的偏移量。

0xA0F5C － 0xA0000 ＝ 0xF5C 。

即：從這個(gè)4K頁面的開始地址，偏移量為0xF5C的地方，才是數(shù)據(jù)段內(nèi)容的開始。

因此對于虛擬地址來說，從0x080e＿9000地址開始，偏移量為0xF5C之后的內(nèi)容才是數(shù)據(jù)段的內(nèi)容，這個(gè)地址值就是：0x080e＿9000 ＋ 0xF5C ＝ 0x080e＿9F5C，如下所示：

這個(gè)地址正是readelf工具讀所顯示的：數(shù)據(jù)段加載到虛擬地址空間中的開始地址，如下所示：

至此，就解釋了文章開頭提出的問題！

再來看一下整個(gè)數(shù)據(jù)段的內(nèi)容：在內(nèi)存中數(shù)據(jù)段占據(jù)的空間是 0x01e48（readelf 工具讀取到的 MemSiz），那么數(shù)據(jù)段的結(jié)束地址就是（虛擬地址）：

0x080e＿9F5C ＋ 0x01e48 ＝ 0x080e＿bda4

如下所示：

小結(jié)

Linux系統(tǒng)中的這個(gè)操作：對屬于不同段的內(nèi)容進(jìn)行重復(fù)映射，有點(diǎn)類似于共享內(nèi)存的味道了。

只不過這里重復(fù)映射之后，每個(gè)段的虛擬地址還是需要修正為該段的合法地址。

經(jīng)過這樣的操作之后，在虛擬地址中每一個(gè)段的界限是涇渭分明的，但是映射到的物理內(nèi)存頁，則有可能是同一個(gè)。