《ucore lab1》實驗報告

資源

練習1：理解經過make生成執行文件的過程

詳見《ucore lab1 exercise1》實驗報告html

練習2：使用qemu執行並調試lab1中的軟件

詳見《ucore lab1 exercise2》實驗報告linux

練習3：分析bootloader進入保護模式的過程

詳見《ucore lab1 exercise3》實驗報告git

練習4：分析bootloader加載ELF格式的OS的過程

詳見《ucore lab1 exercise4》實驗報告github

練習5：實現函數調用堆棧跟蹤函數

詳見《ucore lab1 exercise5》實驗報告app

練習6：完善中斷初始化和處理

詳見《ucore lab1 exercise6》實驗報告ide

擴展練習1：增長一用戶態函數（待完成）

擴展proj4,增長syscall功能，即增長一用戶態函數（可執行一特定系統調用：得到時鐘計數值），當內核初始完畢後，可從內核態返回到用戶態的函數，而用戶態的函數又經過系統調用獲得內核態的服務。函數

擴展練習2：用鍵盤實現用戶模式內核模式切換（待完成）

用鍵盤實現用戶模式內核模式切換。具體目標是：「鍵盤輸入3時切換到用戶模式，鍵盤輸入0時切換到內核模式」。基本思路是借鑑軟中斷(syscall功能)的代碼，而且把trap.c中軟中斷處理的設置語句拿過來。this

調Bug日誌

【2019-1-3】Bug 2：lab1運行到pmm_init時失敗

解決Bug1後，再次執行make qemu仍然失敗，提示如下信息：

ebp:0x00007bf8 eip:0x00007d6e args:0xc031fcfa 0xc08ed88e 0x64e4d08e 0xfa7502a8 
    <unknow>: -- 0x00007d6d --
qemu-system-i386: Trying to execute code outside RAM or ROM at 0x457e0000
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

使用gdb單步跟蹤，發現是在pmm_init函數中加載完gdt表後，執行mov %ax, %gs時異常結束了。我嘗試將gs寄存器改成dx，則沒有問題。這意味着gs等段寄存器此時不能被訪問。spa
問題比較像是某些權限沒設置好，致使沒法訪問段寄存器。應該是前面的步驟哪裏沒作好。發散思路：翻譯
- [x] 梳理一遍從BIOS啓動到pmm_init之間要作哪些事情，檢查各個步驟是否OK，好比保護模式是否設置成功
  - [x] bootloader打開A20門、加載gdt、使能PE（沒問題）
  - kern_init在執行pmm_init以前初始化(edata, end)這段內存
  - [x] kern_init在執行pmm_init以前打印字符串及調試信息（沒影響）
- 查找段寄存器沒法訪問的可能緣由
- 確認加載全局描述符表須要哪些操做，是否有遺漏操做或操做有誤
- 對比lab1和lab2，看下哪些步驟有區別
  - lab1的kernel加載地址爲0x100000，lab2的kernel加載地址爲0xC0100000
  - [x] lab1和lab2的movl %cr0, %eax對應的彙編代碼不一致（使用gdb調試發現沒問題，應該是objdump文件將二進制代碼翻譯成彙編代碼時出現的問題）
最終發現是初始化(edata, end)這段內存致使的問題。這段內存包括.got.plt，.data.rel.local，.bss和.data.rel.ro.local四個段，我縮小爲只初始化.bss段就沒問題了。這個問題以前在作mit 6.828 lab時也遇到過，如今纔想起來。

bin/kernel:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00003955  00100000  00100000  00001000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       000008a0  00103958  00103958  00004958  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .stab         00007bc1  001041f8  001041f8  000051f8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .stabstr      000020cf  0010bdb9  0010bdb9  0000cdb9  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .data         00000950  0010e000  0010e000  0000f000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  5 .got.plt      0000000c  0010e950  0010e950  0000f950  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .data.rel.local 000000c6  0010e960  0010e960  0000f960  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  7 .data.rel.ro.local 0000006c  0010ea40  0010ea40  0000fa40  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  8 .bss          00001300  0010eac0  0010eac0  0000faac  2**5
                  ALLOC
  9 .comment      0000002a  00000000  00000000  0000faac  2**0
                  CONTENTS, READONLY

那麼爲何初始化.got.plt及data.rel.ro.local這些段會有問題？我從RELRO(Relocation Read Only)這個網頁中找到了答案：.data.rel.ro.local這個段顧名思義就知道是隻讀的，如今想將其memset爲0，天然會致使問題。
那麼爲何lab2沒有問題？對比兩個lab的tools/kernel.ld文件，發覺lab2的連接腳本彙總在定義edata前，先用ALIGN命令將位置設置在能被0x1000整除的位置，這樣剛好將.got.plt, data.rel.ro.local這些段跳過了，所以(edata, end)這段內存剛好只包含.bss段，這時memset就沒問題了！

. = ALIGN(0x1000);
    .data.pgdir : {
        *(.data.pgdir)
    }

    PROVIDE(edata = .);

順便貼上lab2的bin/kernel的這幾個段的信息：

5 .got.plt      0000000c  c0118950  c0118950  00019950  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .data.rel.local 000000c6  c0118960  c0118960  00019960  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  7 .data.rel.ro.local 00000088  c0118a40  c0118a40  00019a40  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  8 .data.rel     00000004  c0118ac8  c0118ac8  00019ac8  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  9 .data.pgdir   00002000  c0119000  c0119000  0001a000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
 10 .bss          00000f28  c011b000  c011b000  0001c000  2**5
                  ALLOC

總結：定位問題的常規方法：收集信息、理解原理、推測緣由（將全部可能的緣由都列舉出來，逐一排查）。若是不是以前作mit 6.828 lab遇到過一樣的Bug，估計定位起來更艱難，由於我差異就放棄懷疑memset語句有問題了。這個問題的棘手之處也在於：memset時沒當即出錯，等到後面初始化GDT時纔出錯。總之，經驗很重要，以及不能隨便放過任何一個可能。

【2019-1-3】Bug 1：bootblock連接失敗

從陳渝老師的github代碼庫clone了一份乾淨的代碼到本地，進入labcodes_answer/lab1_result目錄，執行make qemu時失敗了，提示如下信息：

ld -m    elf_i386 -nostdlib -N -e start -Ttext 0x7C00 obj/boot/bootasm.o obj/boot/bootmain.o -o obj/bootblock.o
600 >> 510!!
'obj/bootblock.out' size: 600 bytes
make: \*\*\* [bin/bootblock] Error 255

根據提示信息，可知是連接後的obj/bootblock.out文件大於512字節，致使檢查不經過。這個檢查是在哪裏設置的呢？在代碼庫裏搜索，發現是在tools/sign.c中設置的：

printf("'%s' size: %lld bytes\n", argv[1], (long long)st.st_size);
    if (st.st_size > 510) {
        fprintf(stderr, "%lld >> 510!!\n", (long long)st.st_size);
        return -1;
    }

怎麼解決？先確認一下是否是每一個lab都有這個問題。進入labcodes_answer/lab2_result目錄，執行make qemu成功了，說明lab2是正常的。
爲何lab1和lab2的現象不同呢？有兩種可能：一是連接腳本不一樣，lab2增長了某些連接選項，使得連接後的文件能夠變小；二是代碼文件不一樣，lab1的代碼文件比lab2大。因而首先比較兩個lab的連接腳本，發現基本相同。而後比較兩個lab的diamante文件，發現boot/nootmain.c有如下兩處差別：

// lab1
unsigned int    SECTSIZE  =      512 ;
struct elfhdr * ELFHDR    =      ((struct elfhdr *)0x10000) ;     // scratch space

// lab2
#define SECTSIZE        512
#define ELFHDR          ((struct elfhdr *)0x10000)      // scratch space

能夠推測lab2的寫法是比lab1省內存的，由於使用宏代替了全局變量。但這點差別足夠大到lab1連接不經過嗎？先將lab2的寫法同步到lab1，再make一把，發現果真能夠了，boot/bootblock.out的size由600字節減小到488字節，少了112字節。真神奇，兩個全局變量竟會致使增長了112字節！
總結：定位問題的一種思路：若是有兩份代碼，一份有問題，另外一份正常，那麼可使用對比法。