三級(jí)跳過(guò)程詳解:從 bootloader到操作系統(tǒng),再到應(yīng)用程序
作 者:道哥,10+年的嵌入式開(kāi)發(fā)老兵。
公眾號(hào):【IOT物聯(lián)網(wǎng)小鎮(zhèn)】,專注于:C/C++、Linux操作系統(tǒng)、應(yīng)用程序設(shè)計(jì)、物聯(lián)網(wǎng)、單片機(jī)和嵌入式開(kāi)發(fā)等領(lǐng)域。
轉(zhuǎn) 載:歡迎轉(zhuǎn)載文章,轉(zhuǎn)載需注明出處。
bootloader 跳轉(zhuǎn)到操作系統(tǒng)
操作系統(tǒng)跳轉(zhuǎn)到應(yīng)用程序
應(yīng)用程序調(diào)用操作系統(tǒng)中的函數(shù)
不論是在 x86 平臺(tái)上,還是在嵌入式平臺(tái)上,系統(tǒng)的啟動(dòng)一般都經(jīng)歷了 bootloader 到 操作系統(tǒng),再到應(yīng)用程序,這樣的三級(jí)跳過(guò)程。
每一個(gè)相互交接的過(guò)程,都是我們學(xué)習(xí)的重點(diǎn)。
這篇文章,我們?nèi)匀灰?x86 平臺(tái)為例,一起來(lái)看一下:從上電之后,系統(tǒng)是如何一步一步的進(jìn)入應(yīng)用程序的入口地址。
bootloader 跳轉(zhuǎn)到操作系統(tǒng)
在上一篇文章中,討論了 bootloader 在進(jìn)入保護(hù)模式之后,在地址 0x0001_0000 處創(chuàng)建了全局描述符表(GDT),表中創(chuàng)建了 3 個(gè)段描述符:
只要在 GDT 中創(chuàng)建了這 3 個(gè)描述符,然后把 GDT 的地址(eg: 0x0001_0000)設(shè)置到 GDTR 寄存器中,此時(shí)就可以進(jìn)入保護(hù)模式工作了(設(shè)置 CR0 寄存器的 bit0 為 1)。
之前的第 6 篇文章中Linux從頭學(xué)06:16張結(jié)構(gòu)圖,徹底理解【代碼重定位】的底層原理,我們是假設(shè) bootloader 把操作系統(tǒng)程序讀取到內(nèi)存 0x0002_0000 的位置,這里繼續(xù)使用這個(gè)示例:
關(guān)于文件頭 header 的內(nèi)容,與實(shí)模式下是不同的。
在實(shí)模式下,header 的布局如下圖:
bootloader 在把操作系統(tǒng),從硬盤加載到內(nèi)存中之后,從 header 中取得 3 個(gè)段的匯編地址(即:段的開(kāi)始地址相對(duì)于文件開(kāi)始的偏移量),然后計(jì)算得到段的基地址,最后把段基地址寫回到 header 的這 3 個(gè)段地址空間中。
這樣的話,操作系統(tǒng)開(kāi)始執(zhí)行時(shí),就可以從 header 中準(zhǔn)確的獲取到每一個(gè)段的基地址了,然后就可以設(shè)置相應(yīng)的段寄存器,進(jìn)入正確的執(zhí)行上下文了。
那么在保護(hù)模式下呢,操作系統(tǒng)需要的就不是段的基地址了,而是要獲取到每一個(gè)段的描述符才行。
很顯然,需要借助 bootloader 才可以完成這個(gè)目標(biāo),也就是:
在 GDT 中為操作系統(tǒng)程序中的三個(gè)段,建立相應(yīng)的描述符;
把每一個(gè)段的描述符索引號(hào),寫回到操作系統(tǒng)程序的 header 中;
注意:
這里描述的僅僅是一個(gè)可能的過(guò)程,主要用來(lái)理解原理。
有些系統(tǒng)可以用不同的實(shí)現(xiàn)方式,例如:在進(jìn)入操作系統(tǒng)之后,在另外一個(gè)位置存放 GDT,并重新創(chuàng)建其中的段描述符。
操作系統(tǒng)的 header 布局
既然 header 需要作為媒介,來(lái)接收 bootloader 往其中寫入段索引號(hào),所以 bootloader 與 OS 就要協(xié)商好,寫在什么位置?
可以按照之前的方式,直接覆寫在每個(gè)段的匯編地址位置,也可以寫在其他的位置,例如:
其中,最后的 3 個(gè)位置可以用來(lái)接收操作系統(tǒng)的三個(gè)段索引號(hào)。
建立操作系統(tǒng)的三個(gè)段描述符
bootloader 把 OS 加載到內(nèi)存中之后,會(huì)解析 OS 的 header 中數(shù)據(jù),得到每個(gè)段的基地址以及界限。
雖然 header 中沒(méi)有明確的記錄每個(gè)段的界限,可以根據(jù)下一個(gè)段的開(kāi)始地址,來(lái)計(jì)算得到上一個(gè)段的長(zhǎng)度。
我們可以聯(lián)想一下:
現(xiàn)代 Linux 系統(tǒng)中 ELF 文件的格式,在文件頭部中記錄了每一個(gè)段的長(zhǎng)度,具體解析請(qǐng)參考這篇文章:Linux系統(tǒng)中編譯、鏈接的基石-ELF文件:扒開(kāi)它的層層外衣,從字節(jié)碼的粒度來(lái)探索。
此時(shí),bootloader 就可以利用這幾個(gè)信息:段基地址、界限、類型以及其他屬性,來(lái)構(gòu)造出相應(yīng)的段描述符了(下圖橙色部分):
PS:這里的示例只為操作系統(tǒng)創(chuàng)建了 3 個(gè)段描述符,實(shí)際情況也許有更多的段。
OS 段描述符建立之后,bootloader 再把這 3 個(gè)段描述符在 GDT 中的索引號(hào),填寫到 OS 的 header 中相應(yīng)的位置:
上圖中,“入口地址”下面的那個(gè) 4,本質(zhì)上是不需要的,加上更有好處,好處如下:
當(dāng)從 bootloader 跳入到操作系統(tǒng)的入口地址時(shí),需要告訴處理器兩件事情:
代碼段的索引號(hào);
代碼的入口地址;
因此,把入口地址和索引號(hào)放在一起,有助于 bootloader 直接使用跳轉(zhuǎn)語(yǔ)句,進(jìn)入到 OS 的 start 標(biāo)記處開(kāi)始執(zhí)行。
操作系統(tǒng)跳轉(zhuǎn)到應(yīng)用程序
從現(xiàn)代操作系統(tǒng)來(lái)看,這個(gè)標(biāo)題是有錯(cuò)誤的:
操作系統(tǒng)是應(yīng)用程序的下層支撐,相當(dāng)于是應(yīng)用程序的 runtime,怎么能叫做跳轉(zhuǎn)到應(yīng)用程序呢?
其實(shí)我想表達(dá)的意思是:操作系統(tǒng)是如何加載、執(zhí)行一個(gè)應(yīng)用程序的。
既然是保護(hù)模式,那么操作系統(tǒng)就承擔(dān)起重要的職責(zé):保護(hù)系統(tǒng)不會(huì)受到每一個(gè)應(yīng)用程序的惡意破壞!
因此,操作系統(tǒng):把應(yīng)用程序從硬盤上復(fù)制到內(nèi)存中之后,跳入應(yīng)用程序的第一條指令之前,需要為應(yīng)用程序分配好內(nèi)存資源:
代碼段的基地址、界限、類型和權(quán)限等信息;
數(shù)據(jù)段的基地址、界限、類型和權(quán)限等信息;
棧段的基地址、界限、類型和權(quán)限等信息;
以上這些信息,都以段描述符的形式,創(chuàng)建在 GDT 中。
PS: 在現(xiàn)代操作系統(tǒng)中,應(yīng)用程序都會(huì)有一個(gè)自己私有的局部描述符表 LDT,專門存儲(chǔ)應(yīng)用程序自己的段描述符。
還記得之前討論過(guò)的下面這張圖嗎?
段寄存器的 bit2 位 TI 標(biāo)志,就說(shuō)明了需要到 GDT 中查找段描述符?還是到 LDT 中去查找?
為了方便起見(jiàn),我們就把所有的段描述符都放在 GDT 中。
就猶如 bootloader 為 OS 創(chuàng)建段描述符一樣,OS 也以同樣的步驟為應(yīng)用程序來(lái)創(chuàng)建每一個(gè)段描述符。
此時(shí)的 GDT 就是下面這樣:
從這張圖中已經(jīng)可以看出一個(gè)問(wèn)題了:
如果所有應(yīng)用程序的段描述符都放在全局的 GDT 中,當(dāng)應(yīng)用程序結(jié)束之后,還得去更新 GDT,勢(shì)必給操作系統(tǒng)的代碼帶來(lái)很多麻煩。
因此,更合理的方式應(yīng)該是放在應(yīng)用程序私有的 LDT 中,這個(gè)問(wèn)題,以后還會(huì)進(jìn)一步討論到。
不管怎樣,OS 啟動(dòng)應(yīng)用程序的整體流程如下:
操作系統(tǒng)把應(yīng)用程序讀取到內(nèi)存中的某個(gè)空閑位置;
操作系統(tǒng)分析應(yīng)用程序 header 部分的信息;
操作系統(tǒng)為應(yīng)用程序創(chuàng)建每一個(gè)段描述符,并且把索引號(hào)寫回到 header 中;
跳轉(zhuǎn)到應(yīng)用程序的入口地址,應(yīng)用程序從 header 中獲取到每個(gè)段索引號(hào),設(shè)置好自己的執(zhí)行上下文(即:設(shè)置好各種寄存器);
應(yīng)用程序調(diào)用操作系統(tǒng)中的函數(shù)
這里的函數(shù)可以理解成系統(tǒng)調(diào)用,也就是操作系統(tǒng)為所有的應(yīng)用程序提供的公共函數(shù)。
在 Linux 系統(tǒng)中,系統(tǒng)調(diào)用是通過(guò)中斷來(lái)實(shí)現(xiàn)的,在中斷處理器程序中,再通過(guò)一個(gè)寄存器來(lái)標(biāo)識(shí):當(dāng)前應(yīng)用程序想調(diào)用哪一個(gè)系統(tǒng)函數(shù),也就是說(shuō):每一個(gè)系統(tǒng)函數(shù)都有一個(gè)固定的數(shù)字編號(hào)。
再回到我們當(dāng)前討論的 x86 處理器中,操作系統(tǒng)提供系統(tǒng)函數(shù)的最簡(jiǎn)單的方法就是:
把所有的系統(tǒng)函數(shù)都放在一個(gè)單獨(dú)的代碼段中,把這個(gè)段的索引號(hào)以及每一個(gè)系統(tǒng)函數(shù)的偏移地址告訴應(yīng)用程序。
這樣的話,應(yīng)用程序就可以通過(guò)這 2 個(gè)信息調(diào)用到系統(tǒng)函數(shù)了。
假如:有 2 個(gè)系統(tǒng)函數(shù) os_func1 和 os_func2,放在一個(gè)獨(dú)立的段中:
既然 OS 中多了一個(gè)代碼段,那么 bootloader 就需要幫助它在 GDT 中多創(chuàng)建一個(gè)段描述符:
在應(yīng)用程序的 header 中,預(yù)留一個(gè)足夠大的空間來(lái)存放每一個(gè)系統(tǒng)函數(shù)的跳轉(zhuǎn)信息(系統(tǒng)函數(shù)的段索引號(hào)和函數(shù)的偏移地址):
應(yīng)用程序有了這個(gè)信息之后,當(dāng)需要調(diào)用 os_func1 時(shí),就直接跳轉(zhuǎn)到相應(yīng)的 段索引號(hào):函數(shù)偏移地址,就可以調(diào)用到這個(gè)系統(tǒng)函數(shù)了。
這里同樣的會(huì)引出 2 個(gè)問(wèn)題:
如果操作系統(tǒng)提供的系統(tǒng)函數(shù)很多,應(yīng)用程序也很多,那么操作系統(tǒng)在加載每一個(gè)應(yīng)用程序時(shí),豈不是要忙死了?而且應(yīng)用程序也不知道應(yīng)該保留多大的空間來(lái)存放這些系統(tǒng)函數(shù)的跳轉(zhuǎn)信息;
在執(zhí)行系統(tǒng)函數(shù)時(shí),此時(shí)代碼段、數(shù)據(jù)段都是屬于操作系統(tǒng)的勢(shì)力范圍,但是;泛蜅m斨羔樖褂玫娜匀皇菓(yīng)用程序擁有的棧,這樣合理嗎?
對(duì)于第一個(gè)問(wèn)題,所以 Linux 中通過(guò)中斷,提供一個(gè)統(tǒng)一的調(diào)用入口地址,然后通過(guò)一個(gè)寄存器來(lái)區(qū)分是哪一個(gè)函數(shù)。
對(duì)于第二個(gè)問(wèn)題,Linux 在加載每一個(gè)應(yīng)用程序時(shí),會(huì)在內(nèi)核中建立與該應(yīng)用程序相關(guān)的數(shù)據(jù)結(jié)構(gòu),并且在內(nèi)核中創(chuàng)建一塊內(nèi)存空間,專門用作:從這個(gè)應(yīng)用程序跳轉(zhuǎn)到內(nèi)核中執(zhí)行代碼時(shí),所使用的?臻g

發(fā)表評(píng)論
請(qǐng)輸入評(píng)論內(nèi)容...
請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字
最新活動(dòng)更多
-
3月27日立即報(bào)名>> 【工程師系列】汽車電子技術(shù)在線大會(huì)
-
4月30日立即下載>> 【村田汽車】汽車E/E架構(gòu)革新中,新智能座艙挑戰(zhàn)的解決方案
-
5月15-17日立即預(yù)約>> 【線下巡回】2025年STM32峰會(huì)
-
即日-5.15立即報(bào)名>>> 【在線會(huì)議】安森美Hyperlux™ ID系列引領(lǐng)iToF技術(shù)革新
-
5月15日立即下載>> 【白皮書】精確和高效地表征3000V/20A功率器件應(yīng)用指南
-
5月16日立即參評(píng) >> 【評(píng)選啟動(dòng)】維科杯·OFweek 2025(第十屆)人工智能行業(yè)年度評(píng)選
推薦專題
- 1 UALink規(guī)范發(fā)布:挑戰(zhàn)英偉達(dá)AI統(tǒng)治的開(kāi)始
- 2 北電數(shù)智主辦酒仙橋論壇,探索AI產(chǎn)業(yè)發(fā)展新路徑
- 3 降薪、加班、裁員三重暴擊,“AI四小龍”已折戟兩家
- 4 “AI寒武紀(jì)”爆發(fā)至今,五類新物種登上歷史舞臺(tái)
- 5 國(guó)產(chǎn)智駕迎戰(zhàn)特斯拉FSD,AI含量差幾何?
- 6 光計(jì)算迎來(lái)商業(yè)化突破,但落地仍需時(shí)間
- 7 東陽(yáng)光:2024年扭虧、一季度凈利大增,液冷疊加具身智能打開(kāi)成長(zhǎng)空間
- 8 地平線自動(dòng)駕駛方案解讀
- 9 封殺AI“照騙”,“淘寶們”終于不忍了?
- 10 優(yōu)必選:營(yíng)收大增主靠小件,虧損繼續(xù)又逢關(guān)稅,能否乘機(jī)器人東風(fēng)翻身?