1、操作系統實驗報告課程名稱操作系統實驗實驗項目名稱操作系統的啟動學號班級20100612姓名專業計算機科學與技術學生所在學院計 算 機科 學 與技術學院指導教師實驗室名稱地點計算機基礎第七實驗室 21B475哈爾濱工程大學計算機科學與技術學院 、實驗概述實驗名稱 操作系統的啟動實驗目的1 跟蹤調試 EOS 在 PC 機上從加電復位到成功啟動的全過程， 了解操作系 統的啟動過程。2 查看 EOS啟動后的狀態和行為，理解操作系統啟動后的工作方式。實驗類型 驗證性實驗實驗內容調試 EOS操作系統的啟動過程包括：（1）. 使用 Bochs 做為遠程目標機 ;（2）. 調試 BIOS程序; （ 3）.調試

2、軟盤引導扇區程序 ;（4）. 調試加載程序 ;（5）. 調試 內核; （6）.查看 EOS啟動后的狀態和行為二、實驗環境EOS操作系統和配套的 IDE 集成開發環境。 三、實驗過程設計思路和流程圖CPU 從默認位置執行 BIOS 的開機自檢和初始化程序， 之后 BIOS 將軟盤引導扇區加載到 0 x7C00 并執行。軟盤引導扇區中的 Boot 程序開始執行，將軟盤根目錄 中的 Loader 程序文件 Loader.bin 加載到 0 x1000 并執行Loader 程序開始執行，先加載 Kernel.dll ，然后啟動保 護模式和分頁機制，最后跳到 Kernel.dll 的入口點執行Kerne

3、l.dll 開始執行，初始化 EOS 內核， EOS 啟動完畢圖 2-1.EOS 操作系統的啟動過程流程圖算法實現：驗證性試驗，無算法。需要解決的問題及解答（試驗指導）（1）. 為什么EOS操作系統從軟盤啟動時要使用 boot.bin 和loader.bin 兩個程 序？使用一個可以嗎？它們各自的主要功能是什么？如果將 loader.bin 的功能 移動到boot.bin 文件中，則 boot.bin 文件的大小是否仍然能保持小于 512字節？ 答：boot 文件夾包含了兩個匯編文件 boot.asm 和loader.asm 。這兩個文件生 成的二進制文件 boot.bin 和 loader.

4、bin 會被寫入軟盤鏡像文件。 操作系統啟動時 boot.bin 和loader.bin 引導軟盤加載程序， 二者缺一不可。 使用 Boot.bin 的主要 功能是引導軟盤； loader.bin 的主要功能是加載程序。 如果把 loader.bin 功能移 動到 boot.bin 程序中，必然導致程序規模擴大，可能使其大于 512字節。（2）. 軟盤引導扇區加載完畢后內存中有兩個用戶可用的區域，為什么軟盤 引導扇區程序選擇將 loader.bin 加載到第一個可用區域的 0 x1000處呢？這樣做 有什么好處？這樣做會對 loader.bin 文件的大小有哪些限制。答：首先用戶只用兩個可用區

5、域，加載位置非此即彼。第一個可用用戶區是 低地址區，且空間大小比較小， 適合容納小文件， 所以我們選擇將占用空間小的 loder.bin 加載到第一用戶區。優點：由低地址開始，便于檢索查找。小文件占用小空間，節約資源。 限制： loader.bin 文件必須小于 1c00k.（3）.練習使用Bochs單步調試BIOS程序、軟盤引導扇區程序和 loader 程序， 加深對操作系統啟動過程的理解。（4）. 仔細比較實驗指導 10-5圖和圖 10-6，嘗試說明哪個是應用程序的進程， 它和系統進程有什么區別， 哪個是應用程序的主線程， 它和系統線程有什么區別。答：圖 10-6是應用程序的進程，在進程列

6、表中只有一個 ID為1的系統進程， 其優先級為 24，包含有 10個線程，其中的 ID為2的線程是該進程的主線程，系統 進程沒有映像名稱。在線程列表中有 10個線程，它們都是系統線程。區別：主線程的優先級別高。 存放在物理內存的低端。主要數據結構、實現代碼及其說明：驗證性實驗，無此項目。源程序并附上注釋：驗證性實驗，無此項目。程序運行時的初值和運行結果 ,實驗過程1. 調試 BIOS程序（1）. 在Console窗口中輸入調試命令 sreg 后按回車，顯示當前 CPU中各個 段寄存器的值，如圖 2-1 。其中CS寄存器信息行中的 “s=0 xf000 ”表示CS寄存器的 值為0 xf000.（

7、2）. 輸入調試命令 r后按回車，顯示當前 CPU中各個通用寄存器的值， 如圖 10-3 。其中“rip: 0 x00000000:0000fff0 ”表示IP寄存器的值為 0 xfff0 。. 輸入調試命令 xp /1024b 0 x0000，查看開始的 1024個字節的物理內存。 在Console中輸出的這 1K物理內存的值都為 0，說明 BIOS中斷向量表還沒有被加載 到此處。. 輸入調試命令 xp /512b 0 x7c00，查看軟盤引導扇區應該被加載到的內 存位置。輸出的內存值都為 0，說明軟盤引導扇區還沒有被加載到此處。2. 調試軟盤引導扇區程序輸入調試命令 vb 0 x0000:

8、0 x7c00 ，這樣就在邏輯地址 0 x0000:0 x7c00（相當于 物理地址 0 x7c00）處添加了一個斷點。輸入調試命令 c繼續執行，在 0 x7c00處的斷點中斷。中斷后會在 Console 窗口 中輸出下一個要執行的指令，即軟盤引導扇區程序的第一條指令，如下 （0） 0 x00007c00 0000:7c00 （unk. ctxt）: jmp .+0 x006d （0 x00007c6f） ; eb6d為了方便后面的使用，先在紙上分別記錄下此條指令的字節碼（eb6d）和此條指令要跳轉執行的下一條指令的地址（括號中的 0 x00007c6f ）。輸入調試命令 sreg驗證CS寄存

9、器（ 0 x0000）的值。輸入調試命令 r驗證IP寄存器（ 0 x7c00）的值。由于BIOS程序此時已經執行完畢，輸入調試命令 xp /1024b 0 x0000 驗證此時 BIOS中斷向量表已經被載入。g. 輸入調試命令 xp /512b 0 x7c00顯示軟盤引導扇區程序的所有字節碼。觀察此 塊內存最開始的兩個字節分別為 0 xeb和 0 x6d，這和引導程序第一條指令的字節碼 （ eb6d）是相同的。h. 輸入調試命令 xp /512b 0 x0600 驗證圖 3-2中第一個用戶可用區域是空白的i. 輸入調試命令 xp /512b 0 x7e00 驗證圖 3-2中第二個用戶可用區域是

10、空白的j. 自己設計兩個查看內存的調試命令，分別驗證這兩個用戶可用區域的高地址 端也是空白的。k. 輸入調試命令 xp /512b 0 xa0000 驗證圖 3-2 中上位內存已經被系統占用自己設計一個查看內存的調試命令，驗證上位內存的高地址端已經被系統占 用。查看 boot.lst文件. 在“項目管理器 ”窗口中，右鍵點擊 “boot ”文件夾中的 boot.asm 文件。. 在彈出的快捷菜單中選擇 “打開生成的列表文件 ”，在源代碼編輯器中就會打 開文件 boot.lst 。. 將boot.lst 文件和 boot.asm 文件對比可以發現， 此文件包含了 boot.asm 文件 中所有的

11、匯編代碼，同時在代碼的左側又添加了更多的信息。. 在boot.lst 中查找到軟盤引導扇區程序第一條指令所在的行(第 73行) 73 00000000 EB6D jmp short Start 此行包含的信息有：73是行號。00000000是此條指令相對于程序開始位置的偏移（第一條指令應該為 0）。EB6D是此條指令的字節碼，和之前記錄下來的指令字節碼是一致的。軟盤引導扇區程序的主要任務就是將軟盤中的 loader.bin 文件加載到物理內存 的 0 x1000處，然后跳轉到 loader 程序的第一條指令（物理地址 0 x1000處的指令） 繼續執行loader 程序。按照下面的步驟調試此過

12、程：1）. 在 boot.lst 文件中查找到加載完畢 loader.bin 文件后要跳轉到 loader 程序 中執行的指令（第 278行） 278 00000181 EA00100000 jmp 0:LOADER_ORG根 據 此指令相對于程序開始（ 0 x7C00）的偏移（ 0 x0181）可以得到此指令的邏輯地址 為0 x0000:7D81。2）. 輸入調試命令 vb 0 x0000:0 x7d81 添加一個斷點。3）. 輸入調試命令 c繼續執行，到斷點處中斷。在 Console 窗口中顯示 （0） 0 x00007d81 0000:7d81 （unk. ctxt）: jmp far

13、0000:1000 ; ea00100000此條指令會跳轉到物理內存 0 x1000處（即 Loader程序的第一條指令）繼續執行。4）. 按照打開 boot.lst 文件的方法打開 loader.lst 文件，并在此文件中查找到 loader 程序的第一條指令（第 33行） 33 00000000 E91801 jmp Start5）. 輸入調試命令 xp /8b 0 x1000查看內存 0 x1000處的數據，驗證此塊內存的前 三個字節和 loader.lst 文件中的第一條指令的字節碼是相同的。6）. 根據之前記錄的 loader.bin文件的大小，自己設計一個查看內存的調試命令， 查看

14、內存中 loader程序結束位置的字節碼，并與 loader.lst文件中最后指令的字節 碼比較，驗證 loader程序被完全加載到了正確的位置。調試加載程序Loader 程序的主要任務是將操作系統內核 （kernel.dll 文件）加載到內存中， 然 后讓CPU進入保護模式并且啟用分頁機制，最后進入操作系統內核開始執行（跳 轉到 kernel.dll 的入口點執行）。按照下面的步驟調試上述過程：在loader.lst 文件中查找到準備進入 EOS操作系統內核執行的指令 （第 755行）755 0000014F FF1517010080 call dword va_ImageEntry計算此條

15、指令的物理地址要復雜一些：偏移地址實際上是相對于節(節 SECTION是NASM匯編中的概念)開始的。由于在 boot.asm 程序中只有一個節，所 以之前計算的結果都是正確的， 但是在 loader.asm 程序中有兩個節， 并且此條指 令是在第二個節中。下面引用的代碼是 loader.lst 中第一個節的最后一條指令 (第593行) 593 000003C1 C20600 ret 6 因為第一個節中最后一條指令的偏移 為 0 x03c1，并占用了 3個字節(字節碼為 C20600)，所以可以計算出進入內核執 行的指令所在的物理地址為 0 x1513(0 x1000+0 x03c1+0 x3

16、+0 x14f)。使用添加物理地址斷點的調試命令 pb 0 x1513添加一個斷點。輸入調試命令 c繼續執行，到斷點處中斷。在 Console窗口中顯示要執行的下 一條指令(注意，此時的邏輯地址都為虛擬地址)： (0) 0 x00001513 0008:0000000080001513 (unk. ctxt): call dword ptr ds:0 x80001117 ; ff1517110080 由于這里使用了函數指針的概念，所以，根據反匯編指令可以確 定內核入口點函數的地址就保存在虛擬地址 0 x8000117處的四個字節中。使用查看虛擬內存的調試命令 x /1wx 0 x8000111

17、7查看內存中保存的 32位函數 入口地址，在 Console 窗口中會輸出類似下面的內容： 0 x0000000080001117 : 0 x800* 記錄下此塊內存中保存的函數地址，后面的實驗會驗 證內核入口點函數的地址與此地址是一致的。調試內核：. 在OSL ab的 “項目管理器 ”窗口中打開 ke文件夾中的 start.c 文件，此文件中 只定義了一個函數，就是操作系統內核的入口點函數 KiSystemStartup 。. 在 KiSystemStartup 函數中的代碼行(第 61行) KiInitializePic();添加一個斷點。. 現在可以在 Console 窗口中輸入調試命令

18、 c繼續調試，在剛剛添加的斷點處 中斷。. 在start.c 源代碼文件中的 KiSystemStartup 函數名上點擊鼠標右鍵，在彈 出的快捷菜單中選擇 “添加監視 ”，KiSystemStartup 函數就被添加到了 “監視 ”窗 口中。在 “監視”窗口中可以看到此函數地址為 void (PVOID) 0 x800* 與在虛擬內存 x80001117處保存的函數入口地址相同，說明 的確是由 Loader 程序進入了操作系統內核。. 按F5繼續執行EOS操作系統內核， 在Display 窗口中顯示 EOS操作系統已經啟 動，并且控制臺 程序已經開始運行了。EOS啟動后的狀態和行為1). 在控制臺中輸入命令 “ver ”后按回車。2). 輸出EOS版本后的控制臺如圖 10-4 所示 使用ver命令查看 EOS的版本號。查看EOS啟動后的進程和線程的信息：1). 在控制臺中輸入命令 “pt ”后按回車。2) . 輸出的進程和線程信息如圖所示。查看有應用程序運行時進程和線程的信息：1. 在OS