用Bochs學習Minix(3)-調試啟動過程_彙編

  /boot檔案是一個實模式的可執行檔，運行地址是0x10000，使用反組譯碼工具開啟boot檔案，可以看到boothead.s的第一條指令被編譯在0x1000:0030處。前面已經指出，這就是從bootblock.s跳轉到的位置。這條指令是一個跳轉：

jmp 1002:0015

它實際上就是跳轉到下面一行：

mov ax, 1000  //指令地址：0x10035

…

接下來可以看到代碼一直運行到boothead.s中調用boot函數的彙編代碼：

…

jmp  no_ext

adj_ext:

add  14(di), bx       ! Add ext mem above 16M to mem below 16M

no_ext:

! Time to switch to a higher level language (not much higher)

call  _boot      //調用boot函數

結合/boot檔案的反組譯碼代碼，可以判定boot函數的地址為0x1267a。

啟動Bochs，然後在調試視窗設定斷點後運行：

<bochs:1>pb 0x10124          //設定物理地址斷點

<bochs:2>c

運行一段時間後，Bochs停在了0x10124處。接下來單步運行進入boot函數：

<bochs:3>s

<bochs:4>u /10             //列出反組譯碼代碼

0001267a :(           ): push bp

0001267b :(           ): mov bp, sp

0001267d :(           ): call .+0xe6cb

00012680 :(           ): call .+0xeccc

…

從列出的反組譯碼代碼可以看出execute函數的調用應該在0x1002:266a這一行，所以設定斷點：

<bochs:5>pb 0x1268a

不過遺憾的是系統並沒有在預料的地方停下來，而是一直運行下去了，看來一定是因為某種原因使斷點失效了。經過測試發現，彙編語句在第一個call語句（initialize函數）就沒有返回，這是什麼原因呢。其實只要看一看initialize函數的代碼就可以發現，這個函數把啟動程式拷貝到了low memory（640k）的遠端（far end），也就是接近640k的地方。所以整個啟動代碼的基地址在這個函數中的某一句之後就全部改變了，看來要想完全跟蹤啟動代碼還要費一番功夫。

<bochs:6>pb 0x1267d   //在initialize函數處設定斷點

<bochs:7>s                   //進入函數

<bochs:8>u /20

使拷貝到新地址的啟動程式啟動並執行是initialize函數中調用的第二個過程relocate，它位於boothead.s中。所以可以先找到後面的第二個call指令（即relocate函數）進入，這個彙編函數最後返回的地址就是新定位的地址了。

<bochs:8>pb 0x10e13    //在relocate的入口設定斷點（下一條指令的地址是0x10e16）

<bochs:9>c

<bochs:10>s                 //進入relocate

<bochs:11>u /20

<bochs:12>pb 0x10251  //在relocate返回點設定斷點

<bochs:13>c

<bochs:14>s

可以看間，返回的新地址是0x93606，boot的代碼在機器上被重新置放到了0x93606-0x10e16=0x827f0處。

現在我們可以重新設定execute函數的斷點。它應該位於0x94e7a，所以輸入以下內容：

<bochs:14>pb 0x94e7a

再運行可以發現，Bochs果然停在了預料的位置，看來前面的分析過程沒有問題。接下來就可以進一步跟蹤Minix的啟動過程了。