Linux折騰記（八）：使用GCC和GNU Binutils編寫能在x86實模式運行的16位代碼

　　不可否認，這次的標(biāo)題有點長。之所以把標(biāo)題寫得這么詳細，主要是為了搜索引擎能夠準(zhǔn)確地把確實需要了解GCC生成16位實模式代碼方法的朋友帶到我的博客。先說一下背景，編寫能在x86實模式下運行的16位代碼，這個話題確實有點復(fù)古，所以能找到的資料也相應(yīng)較少。要運行x86實模式的程序，目前我知道的只有兩種方式，一種是使用DOS系統(tǒng)，另一種是把它寫成引導(dǎo)扇區(qū)的代碼，在系統(tǒng)啟動時直接運行。很顯然，許多講自己實現(xiàn)操作系統(tǒng)的書籍都會講到x86實模式，也只有自己實現(xiàn)操作系統(tǒng)引導(dǎo)的朋友需要用到x86實模式，所以我這篇文章的閱讀用戶數(shù)肯定很少，雖然我自認為它填補了網(wǎng)上關(guān)于該話題相關(guān)資料缺乏的空白。因此，凡是逛到我這篇文章的朋友，請點一下推薦，謝謝。

　　為什么說我這篇博客填補了相關(guān)話題的空白呢？那是因為不管是那些寫書的，還是網(wǎng)上寫文章的，一旦需要編寫16位的實模式代碼，都喜歡拿NASM說事兒，一點也不顧GNU AS的感受。當(dāng)然，這是有歷史原因的，因為Linux自從其誕生起就是32位，就是多用戶多任務(wù)操作系統(tǒng)，所以GCC和Gnu AS一移植到Linux上就是用來編寫32位保護模式的代碼的。而且，ELF可執(zhí)行文件格式也只有ELF32和ELF64，沒聽說過有ELF16的。即使是Linux自己，剛誕生的時候（1991年），也只有使用as86匯編器來編寫自己的16位啟動代碼，直到1995年以后，GNU AS才逐步加入編寫16位代碼的能力。

　　下面開始我的GCC和GNU Binutils的16位代碼之旅。我決定使用DOS作為我的測試環(huán)境，所以最后生成的可執(zhí)行文件都把它制作成DOS系統(tǒng)中可運行的Plain Binary格式。第一步安裝一個qemu虛擬機來運行FreeDOS，安裝虛擬機在Ubuntu中只需要一個sudo apt-get install qemu命令就可以完成，所以我就不截圖了。但是FreeDOS的軟盤映像文件需要到Qemu的官網(wǎng)上面去下載，下載地址如下圖：

　　使用qemu-system-i386 -fda freedos.img可以運行Qemu虛擬機和FreeDOS系統(tǒng)，如下圖：

　　因為匯編語言更接近底層，而C語言更高級，所以先從匯編語言開始，逐步過渡到C語言。先寫一個簡單的、能在DOS中顯示一個“Hello，world！”的匯編語言程序，考慮到我之后會使用該程序調(diào)用C語言的main函數(shù)，并且該程序負責(zé)讓程序運行結(jié)束后順利返回DOS系統(tǒng)，所以我把這個程序命名為test_code16_startup.s。其代碼如下：

　　下面對以上代碼進行簡單解釋：

　　1. GNU AS匯編器使用的匯編語言采用的是ATT語法，該語法和Intel語法不同。我更喜歡ATT的語法，原因有兩個，一是ATT語法是Linux世界中通用的標(biāo)準(zhǔn)，二是ATT語法在某些概念方面確實理解起來更簡單（比如內(nèi)存尋址模式）。有匯編語言基礎(chǔ)的人，ATT語法學(xué)起來也很快，主要有以下幾條：①匯編指令后面跟有操作數(shù)長度的后綴，比如mov指令，如果操作數(shù)是8位，則用movb，如果操作數(shù)是16位，則用movw，如果操作數(shù)是32位，則用movl，如果操作數(shù)是64位，則用movq，其余指令依此類推；②操作數(shù)的順序是源操作數(shù)在前，目標(biāo)操作數(shù)在后，比如movw %cs, %ax表示把cs寄存器中的數(shù)據(jù)移動到ax寄存器中，這個順序和Intel匯編語法正好相反；③所有的寄存器使用%前綴，如%ax, %di, %esp等；④對于立即數(shù)，需要使用$前綴，比如 $4,  $0x0c，而且如果一個數(shù)字是以0開頭，則是8進制，以其它數(shù)字開頭，是10進制，以0x開頭則是16進制，標(biāo)號當(dāng)立即數(shù)使用時，需要$前綴，比如上面的pushw $message，而標(biāo)號當(dāng)函數(shù)名使用時，不需要$前綴，比如上面的callw display_str；⑤內(nèi)存尋址方式，眾所周知，x86尋址方式眾多，什么直接尋址、間接尋址、基址尋址、基址變址尋址等等讓人眼花繚亂，而ATT語法對內(nèi)存尋址方式做了一個很好的統(tǒng)一，其格式為section:displacement(base, index, scale)，其中section是段地址，displacement是位移，base是基址寄存器，index是索引，scale是縮放因子，其計算方式為線性地址=section + displacement + base + index*scale，最重要的是，可以省略以上格式中的一個或多個部分，比如movw 4, %ax就是把內(nèi)存地址4中的值移動到ax寄存器中，movw 4(%esp), %ax就是把esp+4指向的地址中的值移動到ax寄存器中，依此類推。我上面的介紹是不是全網(wǎng)絡(luò)最簡明的ATT匯編語法教程？

　　2. 在以上代碼中我全部使用的都是16位的指令，如movw、pushw、callw等，并且直接在代碼中定義了字符串“Hello, world！”。

　　3. 在以上代碼中使用了函數(shù)display_str，在調(diào)用display_str之前，我使用pushw $15和pushw $message將參數(shù)從右向左依次壓棧，然后使用callw指令調(diào)用函數(shù)，這和C語言的函數(shù)調(diào)用約定是一樣的。調(diào)用callw指令會自動將%ip寄存器壓棧，而在函數(shù)開始時，我又用pushw %bp將%bp寄存器壓棧，所以%esp又向下移動了4個字節(jié)，所以在函數(shù)中使用0x4(%esp)和0x6(%esp)可以訪問到這兩個參數(shù)。在32位代碼中，由于調(diào)用函數(shù)時壓棧的是%eip和%ebp，所以需要使用0x8(%esp)和0xc(%esp)來依次訪問壓棧的參數(shù)。關(guān)于匯編語言函數(shù)調(diào)用的細節(jié)，我這里有一本好書Linux匯編編程指南.pdf。這是一本免費的英文版電子書，其原名為《Programming from the ground up》。

　　4. 以上代碼使用BIOS中斷int 0x10來輸出字符串，使用DOS中斷int 0x21來返回DOS系統(tǒng)。

　　5. 最重要的是，需要使用.code16指令讓匯編器將程序匯編成16位的代碼。

　　代碼完成后，使用下面一串命令就可以把它進行匯編、鏈接，然后轉(zhuǎn)換成DOS下的純二進制格式（Plain Binary），最后復(fù)制到FreeDOS.img中，使用Qemu虛擬機執(zhí)行FreeDOS，然后運行該16位實模式程序。這一串命令及其運行效果如下圖：

　　這些命令中比較重要的選項我都特意標(biāo)出來了。由于我用的是64位的環(huán)境，所以調(diào)用as命令的時候需要指定--32選項，調(diào)用ld命令的時候需要指定-m elf_i386選項。指定以上選項后，生成的是32位的ELF目標(biāo)文件，否則默認會生成64位的ELF目標(biāo)文件，如果目標(biāo)文件是64位，以后和C語言生成的目標(biāo)文件連接時會出問題。使用32位環(huán)境的朋友們不用特意指定這兩個選項。由于DOS系統(tǒng)總是把Plain Binary文件載入到0x100地址處執(zhí)行，所以調(diào)用ld命令時，需要指定-Ttext 0x100選項。ld命令執(zhí)行完成后，生成的是ELF格式的可執(zhí)行文件test.elf，最后需要調(diào)用objcopy生成純二進制文件，-j .text選項的意思是只需要代碼段，因為我把“Hello, world!”也是定義在代碼段中的，-O binary選項指定輸出格式為純二進制文件，輸出文件為test.com。最后，將freedos.img鏡像文件mount到Ubuntu中，將test.com拷貝到其中，然后umount，然后運行虛擬機，在DOS中運行test，就可以看到效果了。

　　除了as和ld，GNU Binutils中的其它程序也是寫程序和分析程序時的好幫手?？梢允褂胷eadelf -S查看test.elf文件中的所有段，也可以使用objdump -s命令將test.elf中的數(shù)據(jù)以16進制形式輸入，如下圖：

　　當(dāng)然，也可以使用objdump -d或者objdump -D將程序進行反匯編，查看是否真正生成了16位代碼，如下圖：（反匯編時一定要指定-m i8086選項）

　　也可以對純二進制格式的文件進行反匯編，必須指定-b binary選項，如下圖，對test.com進行反匯編：

　　反匯編時，一定要指定-m i8086選項，否則objdump不知道反匯編的是16位代碼。（前面提到過Linux從誕生起就是32位，所以ELF只有32位和64位兩種，沒有16位的ELF格式。）如下圖，如果使用-m i386選項進行反匯編，反匯編結(jié)果將不知所云：

　　下面進入C語言的世界。為了搞清楚C語言生成的16位代碼的匯編指令有哪些特別之處，先寫一個簡單的C語言程序進行調(diào)研，如下圖：

　　該程序有以下特點：

　　1. 程序的開頭使用了__asm__(".code16\n")嵌入?yún)R編指令，以指示as生成16位代碼；

　　2. display_str函數(shù)的簽名和之前匯編語言中的相同，可以使用它來觀察C語言生成的代碼如何傳遞參數(shù)。

　　使用下面的命令對程序進行編譯和反匯編，如下圖：

　　從上圖可以看出，C語言生成的代碼雖然是16位，但是它有如下特點：①從生成的display_str函數(shù)中可以看出，函數(shù)一開始是push %ebp，而不是push %bp；②在display_str函數(shù)中獲取參數(shù)的位置分別為0x8(%ebp)和0xc(%ebp)，而不是我在匯編語言中寫的0x4(%ebp)和0x6(%ebp)；③從生成的main函數(shù)可以看出，調(diào)用diaplay_str之前，沒有使用push命令把參數(shù)壓棧，而是直接通過sub $0x18, %esp調(diào)整%esp的位置，然后使用mov指令將參數(shù)放到指定位置，和使用push指令的效果相同；④雖然我在display_str函數(shù)的定義中故意將長度參數(shù)定義為short，但是從生成的代碼中可以看到依然是每隔4個字節(jié)放一個參數(shù)。

　　另外需要說明的是，調(diào)用gcc時除了指定-c選項指示它只編譯不連接外，還要指定-m32選項，這樣才會生成32位的匯編代碼，而只有在32位的匯編代碼中使用.code16指令，才能編譯成16位的機器碼。如果沒有指定-m32選項，則生成的是64位匯編代碼，然后匯編時會出錯。使用-m32選項后，生成的目標(biāo)文件是ELF32格式。ELF32格式的目標(biāo)文件只能和ELF32格式的目標(biāo)文件連接，這也是為什么前面的as和ld需要指定--32和-m elf_i386選項的原因。

　　通過以上分析，似乎可以得出以下結(jié)論：只需要將匯編代碼中的pushw %bp更改為pushl %ebp，然后將獲取參數(shù)的位置調(diào)整為0x8(%ebp)和0xc(%ebp)，就可以從C語言里面成功調(diào)用到匯編語言中的函數(shù)了。而事實上，還有一點點小差距。從上面的反匯編代碼中可以看到，函數(shù)調(diào)用時使用的是16位的call指令，該指令壓棧的是%ip，而不是%eip，而C語言生成的函數(shù)框架中獲取的參數(shù)位置是按照將%eip壓棧計算出來的，它們之間差了兩個字節(jié)。

　　為了證明我以上判斷的準(zhǔn)確性，我將上面的C語言程序和匯編程序修改后，編譯連接成一個完整的程序，看看它究竟能否正確運行。如下圖：

　　C語言程序修改很簡單，就是去掉了display_str函數(shù)的實現(xiàn)，只保留聲明。匯編代碼如下圖：

　　匯編語言的更改包含以下幾個地方：將display_str函數(shù)導(dǎo)出，將pushw %bp改為pushl %ebp，同時修改獲取參數(shù)的位置。編譯、連接、運行程序的指令如下：

　　可以看到“Hello world from C language”沒有正確顯示出來。上面的命令都是前面用過的，不需要多解釋，唯一不同的是使用C語言寫的程序多了一個.rodata段，所以在objcopy的時候需要把這個段也包含進來。

　　由于Ｃ語言生成的函數(shù)框架都是從0x8(%ebp)開始取參數(shù)，它認為0x0(%ebp)是old ebp，0x4(%ebp)是%eip，而事實上使用16位的call指令調(diào)用函數(shù)后，0x4(%ebp)中是%ip而不是%eip，所以要從0x6(%ebp)開始取參數(shù)。我們不可能修改C語言生成的函數(shù)框架，只能看看能否將16位的call改成32位的call。

　　辦法當(dāng)然是有的，那就是不使用.code16，而使用.code16gcc。.code16gcc和.code16不同的地方就在于它生成的匯編代碼在使用到call、ret、jump等指令時，都生成32位的機器碼，相當(dāng)于calll，retl，jumpl。這也是.code16gcc叫.code16gcc的原因，因為它就是配合GCC生成的函數(shù)框架使用的。

　　下面再來修改代碼，C語言代碼修改很簡單，只需要將.code16改成.code16gcc即可，如下圖：

　　通過反匯編，可以看到它使用了32位的calll和retl，如下圖：

　　匯編程序的修改主要是將.code16改為.code16gcc，然后手動將callw改成calll，將retw改成retl，如下圖：

　　最后，編譯連接，拷貝到freedos.img，運行虛擬機，查看運行效果，如下圖：

　　大功告成，運行效果如上圖。

　　編寫運行于x86實模式下的16位代碼是一個很復(fù)古的話題，編寫能在DOS下運行的Plain Binary可執(zhí)行文件是一個更復(fù)古的話題。以往，凡是需要使用x86的16位實模式的時候，作者都喜歡用NASM來編程。比如《30天自制操作系統(tǒng)》、《Orange's 一個操作系統(tǒng)的實現(xiàn)》、《x86匯編語言——從實模式到保護模式》等書籍都以NASM匯編器和Intel匯編語法作為示例。而且他們都是在進入32位保護模式后，才讓匯編語言和C語言共同工作。

　　我用Linux操作系統(tǒng)，所以我就是想不管是寫32位代碼，還是16位代碼，都能使用GCC和GNU AS。我還想即使是在16位模式下，也能盡量少用匯編語言，多用C語言。經(jīng)過努力，有了上面的文章。使用GCC和GNU Binutils編寫運行于x86實模式的16位代碼的過程如下：

　　1. 如果只用匯編語言編寫16位程序，請使用.code16指令，并保證只使用16位的指令和寄存器；如果要和C語言一起工作，請使用.code16gcc指令，并且在函數(shù)框架中使用pushl，calll，retl，leavel，jmpl，使用0x8(%ebp)開始訪問函數(shù)的參數(shù)；很顯然，使用C語言和匯編語言混編的程序可以在實模式下運行，但是不能在286之前的真實CPU上運行，因為286之前的CPU還沒有pushl、calll、retl、leavel、jmpl等指令。

　　2. 使用as時，請指定--32選項，使用gcc時，請指定-m32選項，使用ld時，請指定-m elf_i386選項。如果是反匯編16位代碼，在使用objdump時，請使用-m i8086選項。

　　3. 在DOS中運行的.com文件會被加載到0x100處執(zhí)行，所以使用ld連接時需指定-Ttext 0x100選項；引導(dǎo)扇區(qū)的代碼會被加載到0x7c00處執(zhí)行，所以使用ld連接時需指定-Ttext 0x7c00選項。

　　4. 使用gcc、as、ld生成的程序默認都是ELF格式，而在DOS下運行的.com程序是Plain Binary的，在引導(dǎo)扇區(qū)運行的代碼也是Plain Binary的，所以需要使用objcopy將ELF文件中的代碼段和數(shù)據(jù)段拷貝到一個Plain Binary文件中，使用-O binary選項； Plain Binary文件也可以反匯編，在使用objdump時需指定-b binary選項。