第八章存儲管理

1、第八章存儲管理第八章存儲管理n本章主要內(nèi)容：本章主要內(nèi)容：mmummu(memory management unit) 第第 8 章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行

2、文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程 第第 8 章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文

3、件加載流程8.1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理 內(nèi)存管理是操作系統(tǒng)中非常重要的子模內(nèi)存管理是操作系統(tǒng)中非常重要的子模塊。塊。 如同普通操作系統(tǒng)一樣，在嵌入式操作如同普通操作系統(tǒng)一樣，在嵌入式操作系統(tǒng)中，內(nèi)存管理實現(xiàn)的好壞對系統(tǒng)性能有系統(tǒng)中，內(nèi)存管理實現(xiàn)的好壞對系統(tǒng)性能有決定性的作用決定性的作用。8.1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理8.1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理 目前的目前的linuxlinux內(nèi)核已經(jīng)被移植到大量的內(nèi)核已經(jīng)被移植到大量的非非x86x86平臺上，包括平臺上，包括armarm，m68km68k，ppcppc，alphaalpha，sp

4、arcsparc等。等。 其中其中uclinuxuclinux主要針對缺少主要針對缺少mmummu內(nèi)存內(nèi)存管理的優(yōu)秀嵌入式管理的優(yōu)秀嵌入式linuxlinux操作系統(tǒng)。操作系統(tǒng)。8.1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理8.1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理 8.1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理 第第 8章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理

5、的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.2.1 3種內(nèi)存管理模型1. 單一程序模型單一程序模型 這是沒有硬件地址轉(zhuǎn)換的內(nèi)存管理模型。一個應(yīng)用程序可以對所有的物理內(nèi)存地址進(jìn)行尋址 應(yīng)用程序始終在物理內(nèi)存中的同一地址空間運行，一個時刻只有一個應(yīng)用程序被加載運行，程序加載器把應(yīng)用程序加載到內(nèi)存低端，將操作系統(tǒng)加載到高端 2. 多程序模型多程序模型 這也是沒有硬件地址

6、轉(zhuǎn)換的內(nèi)存管理模型。 即使沒有硬件地址轉(zhuǎn)換功能，多個程序也可以共享相同的物理地址。 在程序被加載到內(nèi)存的時候，改變程序中尋址指令(load，store，jump)所使用的地址值為當(dāng)前被加載到的位置。 正是使用了這種模型。uclinux 應(yīng)用程序使用的是虛擬地址，cpu實際執(zhí)行程序所使用的是物理地址，從虛擬地址到物理地址的轉(zhuǎn)換需要操作系統(tǒng)和mmu硬件的參與 標(biāo)準(zhǔn)linux以及大多數(shù)現(xiàn)代操作系統(tǒng)都使用這種內(nèi)存管理模型3. 具有地址轉(zhuǎn)換硬件的內(nèi)存管理模型 第第 8章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模

7、型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.2.2 標(biāo)準(zhǔn)linux的內(nèi)存管理linux使用了上述的第三個模型（地址轉(zhuǎn)換硬件的內(nèi)存管理模型）。 為了理解uclinux對標(biāo)準(zhǔn)linux的裁減，首先必須清楚標(biāo)準(zhǔn)linux中內(nèi)存管理的各種基本概念。這里

8、對相關(guān)于虛擬內(nèi)存的各個概念作一個總結(jié)。 8.2.2 標(biāo)準(zhǔn)linux的內(nèi)存管理8.2.2 標(biāo)準(zhǔn)linux的內(nèi)存管理內(nèi)核主要通過頁目錄和頁表的地址轉(zhuǎn)換功能將內(nèi)核主要通過頁目錄和頁表的地址轉(zhuǎn)換功能將應(yīng)用程序的虛擬地址轉(zhuǎn)換成物理地址。應(yīng)用程序的虛擬地址轉(zhuǎn)換成物理地址。這個過程中可能將應(yīng)用程序中使用的超過了實這個過程中可能將應(yīng)用程序中使用的超過了實際物理內(nèi)存大小的虛擬地址映射到適當(dāng)?shù)恼鎸嵨锢黼H物理內(nèi)存大小的虛擬地址映射到適當(dāng)?shù)恼鎸嵨锢淼刂?，從而使?yīng)用程序可以隨心所欲地使用巨大的地址，從而使應(yīng)用程序可以隨心所欲地使用巨大的虛擬存儲空間虛擬存儲空間( (對對linux 2.4linux 2.4內(nèi)核來說為內(nèi)核

9、來說為4gb)4gb)。8.2.2 標(biāo)準(zhǔn)linux的內(nèi)存管理 但是只通過地址映射還不能解決有限的物理但是只通過地址映射還不能解決有限的物理內(nèi)存被虛擬地址空間所使用的問題，操作系統(tǒng)還內(nèi)存被虛擬地址空間所使用的問題，操作系統(tǒng)還必須使用必須使用頁面交換機(jī)制頁面交換機(jī)制將那些暫時不再使用的內(nèi)將那些暫時不再使用的內(nèi)存空間交換到外存中以使其他程序，能夠使用物存空間交換到外存中以使其他程序，能夠使用物理內(nèi)存。理內(nèi)存。 linuxlinux沒有將整個進(jìn)程所使用的空間都交換到?jīng)]有將整個進(jìn)程所使用的空間都交換到外存中，而是對部分不再使用的大小為外存中，而是對部分不再使用的大小為4kb 4kb 的頁的頁面進(jìn)行交換，

10、這樣就獲得了更多的靈活性面進(jìn)行交換，這樣就獲得了更多的靈活性。 應(yīng)用程序在標(biāo)準(zhǔn)應(yīng)用程序在標(biāo)準(zhǔn)linuxlinux中的加載使用了中的加載使用了“按按需調(diào)頁需調(diào)頁”的策略，也就是說，應(yīng)用程序在開始被的策略，也就是說，應(yīng)用程序在開始被加載的時候并沒有一次被全部裝載到內(nèi)存中，只加載的時候并沒有一次被全部裝載到內(nèi)存中，只有那些現(xiàn)在必需的代碼和數(shù)據(jù)在開始進(jìn)行了加載。有那些現(xiàn)在必需的代碼和數(shù)據(jù)在開始進(jìn)行了加載。 8.2.2 標(biāo)準(zhǔn)linux的內(nèi)存管理 在程序執(zhí)行的過程中，如果遇到了不在內(nèi)存在程序執(zhí)行的過程中，如果遇到了不在內(nèi)存中的程序部分將產(chǎn)生頁面錯誤，操作系統(tǒng)在處理中的程序部分將產(chǎn)生頁面錯誤，操作系統(tǒng)在處理

11、這個錯誤中斷的時候會到外存中找到相應(yīng)的應(yīng)用這個錯誤中斷的時候會到外存中找到相應(yīng)的應(yīng)用程序部分進(jìn)行加載。程序部分進(jìn)行加載。 8.2.2 標(biāo)準(zhǔn)linux的內(nèi)存管理 這種設(shè)計是基于計算機(jī)科學(xué)中著名的90-10規(guī)則的：90的程序執(zhí)行時間花費在整個程序10的代碼上。 所以只要保持我們用到的程序在內(nèi)存中，就可以既滿足程序的執(zhí)行速度又節(jié)約物理內(nèi)存空間。 標(biāo)準(zhǔn)linux中的內(nèi)存管理模型如圖如圖8-1所示所示。 圖圖8-1 linux的內(nèi)存管理模型的內(nèi)存管理模型第第 8章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2

12、.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.2.3 uclinux的內(nèi)存管理 由于由于m68k系列微處理器中沒有分段的系列微處理器中沒有分段的概念，所以標(biāo)準(zhǔn)概念，所以標(biāo)準(zhǔn)linux內(nèi)核中從虛擬地址到內(nèi)核中從虛擬地址到線性地址的映射已經(jīng)不必存在了。線性

13、地址的映射已經(jīng)不必存在了。 而且由于缺少了而且由于缺少了mmu硬件的支持，硬件的支持，uclinux不能支持虛擬內(nèi)存管理和內(nèi)存保護(hù)。不能支持虛擬內(nèi)存管理和內(nèi)存保護(hù)。 8.2.3 uclinux的內(nèi)存管理n這就意味著它完全不使用標(biāo)準(zhǔn)linux內(nèi)核中的分頁管理機(jī)制，也就沒有了頁表和頁目錄對線性地址的映射，從而線性地址到物理地址的轉(zhuǎn)換也是不需要進(jìn)行任何工作的。n換句話說，uclinux中所使用的都是直接物理地址。 8.2.3 uclinux的內(nèi)存管理n而且，由于沒有了虛擬內(nèi)存管理功能，uclinux不再使用“按需調(diào)頁”算法。 這樣在程序載入內(nèi)存執(zhí)行的時候需要將程序的全部映像都一次裝入。n 那些比物理

14、內(nèi)存還大的程序?qū)o法執(zhí)行。8.2.3 uclinux的內(nèi)存管理n 盡管如此，uclinux還是將整個物理內(nèi)存劃分成大小為4kb的頁面。n 由數(shù)據(jù)結(jié)構(gòu)page管理，有多少頁面就有多少page結(jié)構(gòu)，它們又作為元素組成一個數(shù)組mem_map。n 物理頁面可以作為進(jìn)程的代碼、數(shù)據(jù)和堆棧的一部分，還可以存儲裝入的文件，也可以當(dāng)作緩沖區(qū)。8.2.3 uclinux的內(nèi)存管理 uclinux仍然使用標(biāo)準(zhǔn)linux內(nèi)核中的變型buddy system機(jī)制來管理空閑的物理頁面，bitmap表和free_area數(shù)組，以及相關(guān)的函數(shù)或宏_get_free_pages()、free_pages()、_get_fre

15、e_page()現(xiàn)在仍然在被使用。8.2.3 uclinux的內(nèi)存管理n 進(jìn)程可以向核心申請使用物理內(nèi)存。這仍然通過使用傳統(tǒng)的kmalloc()和kfree()實現(xiàn)。n 這些內(nèi)存塊來自于free_area數(shù)組，由blocksize表、size表、page_descriptor結(jié)構(gòu)和block_header結(jié)構(gòu)共同管理。 8.2.3 uclinux的內(nèi)存管理 而過去的vmalloc()和vfree()由于是從虛擬空間3gb以上的虛擬空間的最高端分配內(nèi)存，所以現(xiàn)在對它們的實現(xiàn)只是簡單地調(diào)用kmalloc()和kfree()，實際上分配的也是從空閑物理頁面鏈表中獲得的頁面。8.2.3 uclinux

16、的內(nèi)存管理n 不使用虛擬空間的概念，虛存段結(jié)構(gòu)vm_area_struct以及由它構(gòu)成的線性鏈表和avl樹都不再使用。n 沒有了虛擬內(nèi)存的應(yīng)用，也就不再有將頁面換出到外存中的機(jī)制。n 所以過去的kswapd頁面換出守護(hù)進(jìn)程和交換空間的頁面管理數(shù)據(jù)結(jié)構(gòu)在uclinux中都被刪除。第第 8章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存

17、管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.2.4 uclinux內(nèi)存管理的局限性 由于缺少了mmu硬件的支持，uclinux的多任務(wù)管理功能受到一定限制：1. uclinux中無法實現(xiàn)fork()而只能使用vfork() 這并不意味著uclinux不具有多任務(wù)功能，而是父進(jìn)程在調(diào)用vfork()之后必須在子進(jìn)程調(diào)用exec()或者exit()之前阻塞。8.2.4 uclinux內(nèi)存管理的局限性2. 標(biāo)準(zhǔn)linux中

18、的內(nèi)存分段為應(yīng)用程序提供了接近無限的堆空間和?？臻g，而uclinux為可執(zhí)行程序在緊隨它的數(shù)據(jù)段結(jié)束處分配堆?？臻g。 這樣如果堆增長的太大，它將可能覆蓋程序的靜態(tài)數(shù)據(jù)段和代碼段。8.2.4 uclinux內(nèi)存管理的局限性3. uclinux中沒有自動擴(kuò)展的棧，也沒有brk()調(diào)用。 用戶必須通過使用mmap()來分配內(nèi)存空間。 可以在程序的編譯過程中指定它所使用的棧大小。4. 不具有內(nèi)存保護(hù)。任何程序都有可能導(dǎo)致內(nèi)核崩潰。 8.2.4 uclinux內(nèi)存管理的局限性 uclinux與標(biāo)準(zhǔn)linux的主要區(qū)別在于它針對沒有mmu的處理器進(jìn)行改造。 uclinux所做的修改最大的部分理所當(dāng)然位于內(nèi)

19、存管理部分，而內(nèi)存管理上最大變化就是uclinux沒有使用虛擬內(nèi)存機(jī)制。 8.2.4 uclinux內(nèi)存管理的局限性 這樣，標(biāo)準(zhǔn)linux的內(nèi)存管理模塊中的許多功能實際上都被拋棄了，諸如對頁目錄和頁表的管理，對于交換空間的維護(hù)，頁交換內(nèi)核守護(hù)進(jìn)程和頁面換出功能，缺頁中斷和頁面保護(hù)機(jī)制等。 8.2.4 uclinux內(nèi)存管理的局限性 而為了解決由此產(chǎn)生的新問題，uclinux同時設(shè)計了一種新的可執(zhí)行文件格式：flat，以及修改了部分進(jìn)程管理的代碼：如用vfork()來代替了fork()調(diào)用，實現(xiàn)了無法共享頁面的do_mmap()等。 uclinux下的多任務(wù)管理遠(yuǎn)比linux簡單，因為沒有進(jìn)程的

20、頁表項和保護(hù)機(jī)制要處理。 8.2.4 uclinux內(nèi)存管理的局限性 內(nèi)核的調(diào)度器不需要進(jìn)行修改，唯一需要完成的工作就是進(jìn)行程序上下文的正確保存和恢復(fù)。 這些上下文包括所有的在進(jìn)程被中斷的時候必須保存的寄存器的值。8.2.4 uclinux內(nèi)存管理的局限性 這些機(jī)制的缺少歸根結(jié)底都在于微處理芯片沒有mmu的支持。 例如，在沒有mmu的處理器上不可能實現(xiàn)內(nèi)存共享和保護(hù)，這是由于各種unix的內(nèi)存共享都是需要mmu中的頁表和頁目錄管理功能支持的。 8.2.4 uclinux內(nèi)存管理的局限性 標(biāo)準(zhǔn)linux中的內(nèi)存共享以頁面共享的形式實現(xiàn)，共享該頁的各個進(jìn)程的頁表項直接指向共享頁，當(dāng)共享狀態(tài)發(fā)生變化

21、的時候共享該頁的各進(jìn)程的頁表都進(jìn)行修改。 另一個例子是內(nèi)存保護(hù)機(jī)制的缺少。 8.2.4 uclinux內(nèi)存管理的局限性 標(biāo)準(zhǔn)linux中對內(nèi)存的加鎖保護(hù)是在虛擬內(nèi)存段vma的基礎(chǔ)上進(jìn)行的， 也就是每一個vma段由一個自己的保護(hù)權(quán)限標(biāo)志vm_flags，將這個標(biāo)志設(shè)置成prot_read，prot_ write和prot_exec就可以實現(xiàn)保護(hù)機(jī)制， 但實際上在vma操作的最底層，保護(hù)的實現(xiàn)還是要依靠各個頁面本身的頁表項標(biāo)志。第第 8章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)lin

22、ux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程 在標(biāo)準(zhǔn)linux的啟動過程中要進(jìn)行許多與內(nèi)存管理相關(guān)的功能模塊的初始化工作，諸如頁目錄和頁表映射的建立等。 在把它改造成不使用mmu的系統(tǒng)的過程中必然要對這些功能進(jìn)行修改。 所

23、以在這一部分中將展開對uclinux中內(nèi)存模塊的啟動初始化分析。8.3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程 arch/armnommu/kernel/entry_armv.s是一個匯編文件，它包含了一個kernel_entry的定義，這是整個內(nèi)核的進(jìn)入點。 在完成某些平臺相關(guān)的初始化工作之后，執(zhí)行流程跳轉(zhuǎn)到start_kernel()處。 從這里開始考察uclinux的內(nèi)存模塊啟動初始化是如何實現(xiàn)的。8.3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程 start_kernel()中與內(nèi)存模塊相關(guān)的函數(shù)調(diào)用流程如下：1.setup_arch() 2. paging_init() 3.

24、free_area_init() 4.mem_init()下面分別分析這些函數(shù)各自的功能以及uclinux對它們的改造。1.setup_arch() setup_arch()首先根據(jù)目前內(nèi)核所配置的平臺向某些特定地址寫入特殊字符序列，以完成對特定硬件的初始化， 比如工作狀態(tài)發(fā)光二極管、錯誤和報警發(fā)光二極管等。1.setup_arch() 存儲了可用物理內(nèi)存起始地址的變量memory_start的初始化是通過一個ld腳本中定義的變量_end進(jìn)行的。 ld腳本是用來控制gnu ld連接器在連接內(nèi)核各個目標(biāo)文件部分的時候的配置動作，比如這樣一個腳本：1.setup_arch()sections .=

25、0 x10000； .text ： *（.text） .=0 x8000000； .data ： *（.data） .bss : * (.bss) 1.setup_arch() 用來配置ld連接目標(biāo)文件的時候?qū)⑺心繕?biāo)文件中的存儲程序正文的. text段(section)連接到一起，并且映射到輸出文件的地址0 x10000處，將所有目標(biāo)文件中已初始化的數(shù)據(jù) 1.setup_arch() data段連接到一起并放置到輸出可執(zhí)行文件的0 x8000000地址處，而所有目標(biāo)文件中還未初始化的數(shù)據(jù)段. bss連接起來后映射到輸出文件中緊跟在.data段之后的位置。1.setup_arch() 這個ld

26、配置腳本文件對每個平臺都是不同的。 如為micetek上所使用的uclinux版本使用的ld配置文件為arch/armnommu/vmlinux.lds。 可以通過修改某個平臺上的ld腳本配置文件中的_end變量來達(dá)到配置其可用物理內(nèi)存起始地址的目的。1.setup_arch() setup_arch()在完成對memory_start變量的初始化之后，通過某些特定手段檢測不同類型的內(nèi)存分布情況。 比如為檢測某段地址范圍是否為ram的方法是通過將某個地址的數(shù)據(jù)讀出來，將它加1后寫回內(nèi)存地址中，然后再讀出來和原始數(shù)據(jù)比較看看其值是否成功增加了1，這樣反復(fù)操作兩次，最后將原數(shù)據(jù)恢復(fù)。 1.setu

27、p_arch() 如果是可讀可寫的ram，那么這個測試的結(jié)果就是每次比較都是成功的，否則就不能將這個地址當(dāng)作ram。1.setup_arch() 在setup_arch()中還可能根據(jù)所用平臺進(jìn)行對flashmemory和rom的測試。 在這些平臺相關(guān)的工作完成以后，setup_arch()將對系統(tǒng)運行的第一個進(jìn)程init_task的mm_struct結(jié)構(gòu)中描述地址空間分布的變量start_code，end_code，end_data和brk進(jìn)行初始化，start_code為0，其他三個數(shù)值分別為來自于ld腳本配置文件中定義的相關(guān)變量_etext、_edata和_end。1.setup_arc

28、h() 此后setup_arch()將根據(jù)linux中為系統(tǒng)中的第塊rom/flash memory card所分配的固定的主從設(shè)備號(可以從documentdevicestxt中得到)來創(chuàng)建根文件系統(tǒng)的設(shè)備號，并存儲在后來將要用到的全局變量root_dev中。1.setup_arch() setup_arch()最后完成對系統(tǒng)啟動參數(shù)的保存。 在調(diào)用setup_arch()返回之后，start_kernel()中得到了系統(tǒng)可用物理內(nèi)存的起始和結(jié)束地址，以及系統(tǒng)啟動時的命令行參數(shù)。2. paging_init() 在linux中，paging_init()的一項主要功能是建立頁目錄和頁表，而且

29、將linux移植到不同平臺的過程中非常重要的一個步驟就是修改這個函數(shù)來適應(yīng)新的硬件平臺的虛擬內(nèi)存體系。 2. paging_init() 但是由于在uclinux中不再使用虛擬內(nèi)存機(jī)制，也就不再需要維護(hù)頁目錄和頁表數(shù)據(jù)結(jié)構(gòu)了，所以paging_init()在這里只是為系統(tǒng)啟動的時候保留一部分特殊用途的內(nèi)存區(qū)間。 它返回后，從可以使用的內(nèi)存區(qū)間開始，依次是如下的數(shù)據(jù)結(jié)構(gòu)：2. paging_init()empty_bad_page_table 占用1頁 empty_bad_page 占用1頁 empty_zero_page 占用1頁，并且被初始化為全0 mem_map bitmap2. pagi

30、ng_init() paging_init()函數(shù)在返回前通過調(diào)用free_area_init(start_mem，end_mem)進(jìn)行建立buddy system的映射位圖關(guān)系，以及建立空閑物理頁面鏈表的操作。3. free_area_init() 這個函數(shù)用于建立管理物理頁幀的數(shù)據(jù)結(jié)構(gòu)mem_map，有多少物理頁幀就有多少mem_map_t類型的結(jié)構(gòu)體與之相對應(yīng)。 每個頁面的mem_map_t結(jié)構(gòu)中的flags被標(biāo)明為pg_dma和pg_reserved，并且頁幀號被賦給相應(yīng)的數(shù)值。 同時建立了管理空閑頁面的bitmap映射表，并且所有的位都被清0。4. mem_init() mem_in

31、it()函數(shù)遍歷整個可用物理內(nèi)存地址空間，將每個頁面相對應(yīng)的struct page結(jié)構(gòu)中flags的pg_reserved標(biāo)志位清除，標(biāo)志用戶個數(shù)的count計數(shù)器置1，并同時統(tǒng)計可用物理頁面數(shù)量，然后打印系統(tǒng)的各個內(nèi)存參數(shù)，如可用ram和rom的大小、內(nèi)核代碼段和數(shù)據(jù)段大小等。第第 8章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)

32、存管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.4 可執(zhí)行程序的加載可執(zhí)行程序的加載 在普通的linux中，虛擬內(nèi)存技術(shù)的使用使我們不必關(guān)心一個應(yīng)用程序是從什么地址開始的。 即使所有的應(yīng)用程序都使用同一個連接腳本配置。 8.4 可執(zhí)行程序的加載可執(zhí)行程序的加載n 也就是說，即使它們使用的虛擬地址是重疊的，經(jīng)過頁表和頁目錄的轉(zhuǎn)換之后它們也可以被映射到不同的物理地址。n 但是在uclinux中，由于缺少了mmu的硬件支持，

33、在內(nèi)核中不會發(fā)生地址的映射轉(zhuǎn)換，這樣就必須解決應(yīng)用程序的加載問題。8.4 可執(zhí)行程序的加載可執(zhí)行程序的加載n uclinux系統(tǒng)使用flat可執(zhí)行文件格式，gcc的編譯器不能直接形成這種文件格式，n 但是可以首先編譯生成coff可執(zhí)行格式或者elf可執(zhí)行格式的文件，n 然后使用格式轉(zhuǎn)化工具(coff2flt或者elf2flt)將這些中間代碼轉(zhuǎn)換成flat文件格式。8.4 可執(zhí)行程序的加載可執(zhí)行程序的加載n當(dāng)用戶執(zhí)行一個flat格式的可執(zhí)行程序時，內(nèi)核的執(zhí)行文件加載器將對flat文件進(jìn)行進(jìn)一步處理，主要是對reloc段進(jìn)行修正。n下面對do_load_flat_binary()函數(shù)的分析將詳細(xì)描

34、述其實現(xiàn)過程。 第第 8章章 目錄目錄1 1 缺少缺少mmummu支持的內(nèi)存管理支持的內(nèi)存管理2 flat2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 32.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linuxlinux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc4.2 reloc段機(jī)制段機(jī)制

35、4.3 flat4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.4.1 用戶程序的內(nèi)存分布 1.堆堆 標(biāo)準(zhǔn)linux上用戶程序的動態(tài)內(nèi)存分配是通過調(diào)用glibc庫的malloc函數(shù)從程序的堆空間中獲得內(nèi)存頁面。 在虛擬內(nèi)存系統(tǒng)中malloc是使用sbrk調(diào)用將程序的數(shù)據(jù)段向后擴(kuò)展得到。 應(yīng)用程序的內(nèi)存使用分布圖如圖8-2所示。圖 8-2 flat可執(zhí)行文件格式8.4.1 用戶程序的內(nèi)存分布 而在uclinux的平地址模式中，堆空間是通過mmap調(diào)用獲得的。 uclibc中的malloc函數(shù)是一個非常簡單的實現(xiàn)，它將所有分配內(nèi)存的細(xì)節(jié)都交給了內(nèi)核

36、。 2. 棧 uclinux中的棧緊隨著用戶程序的數(shù)據(jù)段，而堆是從棧底向下擴(kuò)張的，如圖8-2所示。 由于uclinux中沒有內(nèi)存保護(hù)機(jī)制，這樣必須在程序編譯連接的時候就確保為棧保留了足夠的空間使它不會覆蓋程序的數(shù)據(jù)段和代碼段。圖 8-2 flat可執(zhí)行文件格式第第 8章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程

37、4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.4.2 reloc段機(jī)制 一個可執(zhí)行程序通常包含代碼段、數(shù)據(jù)段、堆棧段、未初始化數(shù)據(jù)段。 在普通的linux系統(tǒng)上，程序連接的時候，連接器ld都要受一個叫做連接器腳本的配置文件所控制，這個腳本用連接器命令語言寫成，連接器會根據(jù)它來決定將程序的各個段加載到內(nèi)存中的什么位置。8.4.2 reloc段機(jī)制 但是由于uclinux中沒有使用虛擬內(nèi)存機(jī)制，也就沒有了從虛擬地址到物理地址之間的映射， 所

38、以程序連接時所指定的程序運行空間在uclinux中成為實際的物理地址而不是像linux那樣可以通過內(nèi)核維護(hù)的頁目錄和頁表來映射到任意物理地址空間。 8.4.2 reloc段機(jī)制 在后面的分析中可以看到，程序加載的時候它所加載的地址是由內(nèi)核的頁面分配機(jī)制所決定的，在程序加載之前不可能被預(yù)知。 這樣就形成了一個矛盾：程序連接時連接器所假定的程序運行空間與實際程序加載到的內(nèi)存空間可能不同。 比如下面的一條指令： bl app_start； 這一條指令采用直接尋址，跳轉(zhuǎn)到app_start地址處執(zhí)行，連接程序?qū)⒃诰幾g完成時按照連接器1d的配置文件計算出app_start的實際地址(設(shè)若實際地址為oxl

39、0000)， 這個實際地址是根據(jù)ld的配置文件做出的假設(shè)(因為連接器總是假定該程序?qū)⒈患虞d到由ld配置文件指明的內(nèi)存空間)。 8.4.2 reloc段機(jī)制注：但實際上操作系統(tǒng)在加載程序時根本沒有考慮到要按照ld配置文件規(guī)定的地址進(jìn)行加載。 這時如果程序仍然跳轉(zhuǎn)到絕對地址oxl0000處執(zhí)行，通常情況這是不正確的。 uclinux采用的解決辦法是在連接生成的可執(zhí)行文件中增加一個變量用于在程序加載的時候動態(tài)修正app_start的實際地址8.4.2 reloc段機(jī)制 這實際上是一塊32位的空間，前30位用來紀(jì)錄程序中的那些標(biāo)明絕對地址的變量在數(shù)據(jù)段中離數(shù)據(jù)段的開始位置的偏移量， 后2位用來標(biāo)明這個

40、變量究竟是指示一個什么地址：分為代碼地址，數(shù)據(jù)地址和未初始化數(shù)據(jù)地址三種， 以便于在程序加載的時候，相應(yīng)程序的代碼段，數(shù)據(jù)段和bss段被加載到內(nèi)存中的實際位置對這個地址變量做出相應(yīng)調(diào)整。 在上面的例子中，對于程序中的標(biāo)明地址值的變量app_start就需要這樣一個flat_reloc結(jié)構(gòu)的變量。 設(shè)若使用變量addr表示這個變量的存儲空間，則addr的前30位記錄了app_start離數(shù)據(jù)段開始位置的偏移量。 因為這個地址app_start是跳轉(zhuǎn)代碼執(zhí)行地址，所以addr的后2位被賦值為flat_reloc_type_text(數(shù)值為0)。 8.4.2 reloc段機(jī)制 增加的4字節(jié)變量add

41、r被存放在稱為reloc的段內(nèi)。 程序中的所有的這樣的變量被連續(xù)存放在可執(zhí)行文件的頭部reloc段中。 連接器連接程序的時候，變量app_start存儲的是根據(jù)ld配置腳本計算出的地址，通常只是距離代碼段、數(shù)據(jù)段或者bss段頭的相對偏移量。 8.4.2 reloc段機(jī)制 在可執(zhí)行文件加載時，可執(zhí)行文件加載器遍歷可執(zhí)行文件頭部的整個reloc段，對每一個其中的flat_reloc類型的變量首先根據(jù)offset的值得到它所對應(yīng)的地址變量在數(shù)據(jù)段中的位置8.4.2 reloc段機(jī)制 然后根據(jù)type的值將這個數(shù)據(jù)段中的地址變量加上程序在物理內(nèi)存中的實際的代碼段，數(shù)據(jù)段和bss段的起始地址進(jìn)行修正。

42、這樣程序中的地址變量中保存的就是正確的物理地址。第第 8章章 目錄目錄1 缺少缺少mmu支持的內(nèi)存管理支持的內(nèi)存管理2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linux的內(nèi)存管理的內(nèi)存管理 2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc段機(jī)制段機(jī)制 4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.4.3

43、 flat可執(zhí)行文件格式 為了適應(yīng)uclinux中新的內(nèi)存管理模式而引入了一種專為它所使用的flat可執(zhí)行文件格式。 可執(zhí)行文件頭是前面描述的reloc段，緊接著是程序的文本段、數(shù)據(jù)段、未初始化數(shù)據(jù)段。 可執(zhí)行文件加載到內(nèi)存之后程序的堆棧段緊隨在bss段的后面。8.4.3 flat可執(zhí)行文件格式 flat可執(zhí)行文件格式如圖如圖8-2所示所示。 但是注意在可執(zhí)行文件被加載到內(nèi)存的時候reloc段仍然在外存中。圖 8-2 flat可執(zhí)行文件格式8.4.3 flat可執(zhí)行文件格式n 每實現(xiàn)一個可執(zhí)行二進(jìn)制文件格式，只要通過調(diào)用內(nèi)核文件系統(tǒng)中的register_ binfmt( )函數(shù)將一個struc

44、t linux_binfmt類型的結(jié)構(gòu)注冊到內(nèi)核中。n 這個結(jié)構(gòu)中包含了這種文件格式的執(zhí)行文件加載器，共享庫加載器和core dump內(nèi)存鏡像文件生成器：include/linux/binfmts.h：struct linux_binfmt struct linux_binfmt *next； long *use_count； int (*load_binary)(struct linux_binprm *， struct pt_regs * regs)； int (*load_shlib)(int fd)； int (*core_dump)(long signr,struct pt_regs

45、 * regs)； 其中l(wèi)oad_binary函數(shù)是每一個二進(jìn)制文件格式的實現(xiàn)都必須提供的，而其他的兩個函數(shù)指針可以為空， 比如在uclinux中，由于內(nèi)存管理的特定方式?jīng)Q定了不能使用代碼的共享，所有的可執(zhí)行程序都在編譯時進(jìn)行了靜態(tài)庫的連接 8.4.3 flat可執(zhí)行文件格式 所以沒有必要實現(xiàn)運行時動態(tài)加載連接庫的功能，而且uclinux也沒有實現(xiàn)core dump機(jī)制的支持， 所以它的flat可執(zhí)行文件格式注冊過程是這樣的：static struct linux_binfmt flat_format = #ifndef module null,null,load_flat_binary,nu

46、ll,null#else null,&mode_use_count_,load_flat_binary,null,null#endif；register_binfmt(&flat_format)； 注冊完成后，內(nèi)核文件系統(tǒng)在加載flat binary格式的可執(zhí)行程序的時候自動調(diào)用load_flat_binary( )函數(shù)完成加載。第第 8章章 目錄目錄1 1 缺少缺少mmummu支持的內(nèi)存管理支持的內(nèi)存管理2 flat2 flat平模式內(nèi)存管理平模式內(nèi)存管理 2.1 32.1 3種內(nèi)存管理模型種內(nèi)存管理模型 2.2 2.2 標(biāo)準(zhǔn)標(biāo)準(zhǔn)linuxlinux的內(nèi)存管理的內(nèi)存管理 2.

47、3 uclinux2.3 uclinux內(nèi)存管理內(nèi)存管理 2.4 uclinux2.4 uclinux內(nèi)存管理的局限性內(nèi)存管理的局限性3 3 內(nèi)存管理模塊的啟動過程內(nèi)存管理模塊的啟動過程4 4 可執(zhí)行程序的加載可執(zhí)行程序的加載 4.1 4.1 用戶程序的內(nèi)存分布用戶程序的內(nèi)存分布 4.2 reloc4.2 reloc段機(jī)制段機(jī)制 4.3 flat4.3 flat可執(zhí)行文件格式可執(zhí)行文件格式 4.4 4.4 執(zhí)行文件加載流程執(zhí)行文件加載流程8.4.4 執(zhí)行文件加載流程n 下面考察一個磁盤上的可執(zhí)行文件是如何被加載到內(nèi)存中并執(zhí)行的。n 在已注冊的flat可執(zhí)行文件加載器被調(diào)用的時候，load_fl

48、at_binary()通過調(diào)用do_load_flat_binary()函數(shù)完成加載功能。8.4.4 執(zhí)行文件加載流程 每一個應(yīng)用程序在內(nèi)核中對應(yīng)一個進(jìn)程，由一個進(jìn)程控制塊描述，也就是task_struct結(jié)構(gòu)。 在調(diào)用do_load_flat_binary()的時候，已經(jīng)為這個任務(wù)的運行創(chuàng)建了進(jìn)程上下文環(huán)境，包括task_struct結(jié)構(gòu)空間的分配和初始化。 8.4.4 執(zhí)行文件加載流程 do_load_flat_binary()所要完成的就是從磁盤文件中按照可執(zhí)行文件的格式讀取可執(zhí)行文件的各個段到ram中(正文段可以在rom中執(zhí)行， 所以可能并不加載到ram內(nèi)存中，而數(shù)據(jù)段、未初始化數(shù)據(jù)段

49、bss必須被加載到ram中，程序的堆?？臻g也必須在ram中被分配)。 8.4.4 執(zhí)行文件加載流程 并且由于flat binary的特性，還要在必要的時候進(jìn)行reloc段的內(nèi)存偏移量修正。 函數(shù)do_load_flat_binary()負(fù)責(zé)實際加載二進(jìn)制文件的工作，其定義如下：inline int do_load_flat_binary(struct linux_binprm * prm,struct pt_regs * regs)； 其中函數(shù)do_load_flat_binary( )的參數(shù)bprm是一個如下類型的結(jié)構(gòu)變量： include/linux/binfmts.h: struct l

50、inux_binprm char buf128； #ifndef no_mm unsigned long pagemax_arg_pages； #else /*!no_mm */ char * envp,*argv；#endif /* ！no_mm */ unsigned long p； int sh_bang； struct inode * inode； int e_uid,e_gid； int argc,envc； char * filename； /*name of binary */ unsigned long loader,exec； int dont_iput； /*binfmt

51、handler has put inode */；8.4.4 執(zhí)行文件加載流程 它用來在加載各種可執(zhí)行文件的時候存儲參數(shù)信息。 在加載flat_bin格式的可執(zhí)行文件的情況下，開始的buf域?qū)嶋H上存儲了一個struct flat_hdr類型的結(jié)構(gòu)變量（只使用了64個字節(jié)）。 envp和argv是執(zhí)行程序時的環(huán)境變量指針列表和參數(shù)指針列表。 inode是可執(zhí)行文件在文件系統(tǒng)中的inode指針，通過它可以得到這個文件的所有相關(guān)信息。 filename是這個可執(zhí)行文件在磁盤上的文件名的字符串指針等。 其中buf域中保持的flat_hdr結(jié)構(gòu)用于每個flat binary格式的磁盤文件的格式描述，定義

52、如下：include/asm-armnommu/flat.hstruct flat_hdr char magic4； unsigned long rev； unsigned long entry； /* offset of first executable instruction with text segment from beginning of file */unsigned long data_start； /*offset of data segment from beginning of file*/unsigned long bss_end； /*offset of end of

53、 bss segment from beginning of file */ /*(it is assumed that data_end through bss_end forms the bss segment.)*/ unsigned long stack_size； /*size of stack,in bytes */ unsigned long reloc_start； /* offset of relocation records from beginning of file */ unsigned long reloc_count； /* number of relocatio

54、n records */ unsigned long flags； unsigned long filler6； /*reserbered,set to zero*/; magic字符數(shù)組中必須包含字符串“bflt”，其他的各個變量描述了在這個flatbinary可執(zhí)行文件中各個段的起始位置離文件頭的偏移量和長度，并且說明了這個文件中的reloc結(jié)構(gòu)數(shù)組離文件頭的偏移量和數(shù)組項個數(shù)。 do_load_flat_binary()的流程如下： 1. 首先調(diào)用flush_o1d_exec()根據(jù)當(dāng)前進(jìn)程(current)的mm_struct結(jié)構(gòu)創(chuàng)建一個新的mm_struct結(jié)構(gòu)，它的引用計數(shù)器cou

55、nt設(shè)為1，占用內(nèi)存頁面數(shù)rss為0，tblock.rblock和tblock.next置為0， 然后將task_struct中的mm指針指向這個mm_struct結(jié)構(gòu)，將原來的mm_struct以及它所包含的內(nèi)存空間使用kfree()釋放。 這個過程結(jié)束后，當(dāng)前進(jìn)程只有個新分配的mm_struct結(jié)構(gòu)，它里面不包含任何內(nèi)存空間。2. 調(diào)用do_mmap()嘗試將根據(jù)調(diào)用參數(shù)bprm中的inode所代表的文件映射到當(dāng)前進(jìn)程管理的內(nèi)存空間中： error = do_mmap(file, 0, code_len + data_len + bss_len + stack_len， prot_read|prot_exec|(hdr -flags & flat_flag_ram) prot_write : 0), 0 /*map_ * */, 0)；0第二步第二步 其中進(jìn)行映射的文件內(nèi)容包括正文段、數(shù)據(jù)段、未初始化數(shù)據(jù)段，以及預(yù)先計算出來的需要保留大小的堆棧段。 映射的保護(hù)權(quán)限設(shè)置為可讀、可執(zhí)行，并且根據(jù)hdr中的調(diào)用參數(shù)flag中是否有flat_flag_ram被設(shè)置(表明是否希望在rom中直接執(zhí)行還是裝載到ram中再執(zhí)行)而決定是否設(shè)置可寫位。 do_mmap()根據(jù)flags參數(shù)決定是否真正進(jìn)行ram映射，