使用GCC和GNU Binutils编写能在x86实模式运行的16位代码
不可否认，这次的标题有点长。之所以把标题写得这么详细，主要是为了搜索引擎能够准确地把确实需要了解GCC生成16位实模式代码方法的朋友带到我的博客。先说一下背景，编写能在x86实模式下运行的16位代码，这个话题确实有点复古，所以能找到的资料也相应较少。要运行x86实模式的程序，目 前我知道的只有两种方式，一种是使用DOS系统，另一种是把它写成引导扇区的代码，在系统启动时直接运行。很显然，许多讲自己实现操作系统的书籍都会讲到 x86实模式，也只有自己实现操作系统引导的朋友需要用到x86实模式，所以我这篇文章的阅读用户数肯定很少，虽然我自认为它填补了网上关于该话题相关资 料缺乏的空白。因此，凡是逛到我这篇文章的朋友，请点一下推荐，谢谢。
为什么说我这篇博客填补了相关话题的空白呢？那是因为不管是那些写书的，还是网上写文章的，一旦需要编写16位的实模式代码，都喜欢拿NASM 说事儿，一点也不顾GNU AS的感受。当然，这是有历史原因的，因为Linux自从其诞生起就是32位，就是多用户多任务操作系统，所以GCC和Gnu AS一移植到Linux上就是用来编写32位保护模式的代码的。而且，ELF可执行文件格式也只有ELF32和ELF64，没听说过有ELF16的。即使 是Linux自己，刚诞生的时候（1991年），也只有使用as86汇编器来编写自己的16位启动代码，直到1995年以后，GNU AS才逐步加入编写16位代码的能力。
下面开始我的GCC和GNU Binutils的16位代码之旅。我决定使用DOS作为我的测试环境，所以最后生成的可执行文件都把它制作成DOS系统中可运行的Plain Binary格式。第一步安装一个qemu虚拟机来运行FreeDOS，安装虚拟机在Ubuntu中只需要一个sudo apt-get install qemu命令就可以完成，所以我就不截图了。但是FreeDOS的软盘映像文件需要到Qemu的官网上面去下载，下载地址如下图：
使用qemu-system-i386 -fda freedos.img可以运行Qemu虚拟机和FreeDOS系统，如下图：
因为汇编语言更接近底层，而C语言更高级，所以先从汇编语言开始，逐步过渡到C语言。先写一个简单的、能在DOS中显示一个 “Hello，world！”的汇编语言程序，考虑到我之后会使用该程序调用C语言的main函数，并且该程序负责让程序运行结束后顺利返回DOS系统， 所以我把这个程序命名为test_code16_startup.s。其代码如下：
下面对以上代码进行简单解释：
1. GNU AS汇编器使用的汇编语言采用的是AT&T语法，该语法和Intel语法不同。我更喜欢AT&T的语法，原因有两个，一是 AT&T语法是Linux世界中通用的标准，二是AT&T语法在某些概念方面确实理解起来更简单（比如内存寻址模式）。有汇编语言基础的 人，AT&T语法学起来也很快，主要有以下几条：①汇编指令后面跟有操作数长度的后缀，比如mov指令，如果操作数是8位，则用movb，如果操 作数是16位，则用movw，如果操作数是32位，则用movl，如果操作数是64位，则用movq，其余指令依此类推；②操作数的顺序是源操作数在前， 目标操作数在后，比如movw %cs, %ax表示把cs寄存器中的数据移动到ax寄存器中，这个顺序和Intel汇编语法正好相反；③所有的寄存器使用%前缀，如%ax, %di, %esp等；④对于立即数，需要使用$前缀，比如 $4, $0x0c，而且如果一个数字是以0开头，则是8进制，以其它数字开头，是10进制，以0x开头则是16进制，标号当立即数使用时，需要$前缀，比如上面的pushw $message，而标号当函数名使用时，不需要$前缀，比如上面的callw display_str；⑤内存寻址方式，众所周知，x86寻址方式众多，什么直接寻址、间接寻址、基址寻址、基址变址寻址等等让人眼花缭乱，而AT&T语法对内存寻址方式做了一个很好的统一，其格式为section:displacement(base, index, scale)， 其中section是段地址，displacement是位移，base是基址寄存器，index是索引，scale是缩放因子，其计算方式为线性地 址=section + displacement + base + index*scale，最重要的是，可以省略以上格式中的一个或多个部分，比如movw 4, %ax就是把内存地址4中的值移动到ax寄存器中，movw 4(%esp), %ax就是把esp+4指向的地址中的值移动到ax寄存器中，依此类推。我上面的介绍是不是全网络最简明的AT&T汇编语法教程？
2. 在以上代码中我全部使用的都是16位的指令，如movw、pushw、callw等，并且直接在代码中定义了字符串“Hello, world！”。
3. 在以上代码中使用了函数display_str，在调用display_str之前，我使用pushw $15和pushw $message 将参数从右向左依次压栈，然后使用callw指令调用函数，这和C语言的函数调用约定是一样的。调用callw指令会自动将%ip寄存器压栈，而在函数开 始时，我又用pushw %bp将%bp寄存器压栈，所以%esp又向下移动了4个字节，所以在函数中使用0x4(%esp)和0x6(%esp)可以访问到这两个参数。在32位 代码中，由于调用函数时压栈的是%eip和%ebp，所以需要使用0x8(%esp)和0xc(%esp)来依次访问压栈的参数。关于汇编语言函数调用的 细节，我这里有一本好书Linux汇编编程指南.pdf。这是一本免费的英文版电子书，其原名为《Programming from the ground up》。
4. 以上代码使用BIOS中断int 0x10来输出字符串，使用DOS中断int 0x21来返回DOS系统。
5. 最重要的是，需要使用.code16指令让汇编器将程序汇编成16位的代码。
代码完成后，使用下面一串命令就可以把它进行汇编、链接，然后转换成DOS下的纯二进制格式（Plain Binary），最后复制到FreeDOS.img中，使用Qemu虚拟机执行FreeDOS，然后运行该16位实模式程序。这一串命令及其运行效果如下图：
这些命令中比较重要的选项我都特意标出来了。由于我用的是64位的环境，所以调用as命令的时候需要指定--32选项，调用ld命令的时候需要 指定-m elf_i386选项。指定以上选项后，生成的是32位的ELF目标文件，否则默认会生成64位的ELF目标文件，如果目标文件是64位，以后和C语言生 成的目标文件连接时会出问题。使用32位环境的朋友们不用特意指定这两个选项。由于DOS系统总是把Plain Binary文件载入到0x100地址处执行，所以调用ld命令时，需要指定-Ttext 0x100选项。ld命令执行完成后，生成的是ELF格式的可执行文件test.elf，最后需要调用objcopy生成纯二进制文件，-j .text选项的意思是只需要代码段，因为我把“Hello, world!”也是定义在代码段中的，-O binary选项指定输出格式为纯二进制文件，输出文件为test.com。最后，将freedos.img镜像文件mount到Ubuntu中，将 test.com拷贝到其中，然后umount，然后运行虚拟机，在DOS中运行test，就可以看到效果了。
除了as和ld，GNU Binutils中的其它程序也是写程序和分析程序时的好帮手。可以使用readelf -S查看test.elf文件中的所有段，也可以使用objdump -s命令将test.elf中的数据以16进制形式输入，如下图：
当然，也可以使用objdump -d或者objdump -D将程序进行反汇编，查看是否真正生成了16位代码，如下图：（反汇编时一定要指定-m i8086选项）
也可以对纯二进制格式的文件进行反汇编，必须指定-b binary选项，如下图，对test.com进行反汇编：
反汇编时，一定要指定-m i8086选项，否则objdump不知道反汇编的是16位代码。（前面提到过Linux从诞生起就是32位，所以ELF只有32位和64位两种，没有 16位的ELF格式。）如下图，如果使用-m i386选项进行反汇编，反汇编结果将不知所云：
下面进入C语言的世界。为了搞清楚C语言生成的16位代码的汇编指令有哪些特别之处，先写一个简单的C语言程序进行调研，如下图：
该程序有以下特点：
1. 程序的开头使用了__asm__(".code16\n")嵌入汇编指令，以指示as生成16位代码；
2. display_str函数的签名和之前汇编语言中的相同，可以使用它来观察C语言生成的代码如何传递参数。
使用下面的命令对程序进行编译和反汇编，如下图：
从上图可以看出，C语言生成的代码虽然是16位，但是它有如下特点：①从生成的display_str函数中可以看出，函数一开始是push %ebp，而不是push %bp；②在display_str函数中获取参数的位置分别为0x8(%ebp)和0xc(%ebp)，而不是我在汇编语言中写的0x4(%ebp)和 0x6(%ebp)；③从生成的main函数可以看出，调用diaplay_str之前，没有使用push命令把参数压栈，而是直接通过sub $0x18, %esp调整%esp的位置，然后使用mov指令将参数放到指定位置，和使用push指令的效果相同；④虽然我在display_str函数的定义中故意 将长度参数定义为short，但是从生成的代码中可以看到依然是每隔4个字节放一个参数。
另外需要说明的是，调用gcc时除了指定-c选项指示它只编译不连接外，还要指定-m32选项，这样才会生成32位的汇编代码，而只有在32位 的汇编代码中使用.code16指令，才能编译成16位的机器码。如果没有指定-m32选项，则生成的是64位汇编代码，然后汇编时会出错。使用-m32 选项后，生成的目标文件是ELF32格式。ELF32格式的目标文件只能和ELF32格式的目标文件连接，这也是为什么前面的as和ld需要指定--32 和-m elf_i386选项的原因。
通过以上分析，似乎可以得出以下结论：只需要将汇编代码中的pushw %bp更改为pushl %ebp，然后将获取参数的位置调整为0x8(%ebp)和0xc(%ebp)，就可以从C语言里面成功调用到汇编语言中的函数了。而事实上，还有一点点 小差距。从上面的反汇编代码中可以看到，函数调用时使用的是16位的call指令，该指令压栈的是%ip，而不是%eip，而C语言生成的函数框架中获取 的参数位置是按照将%eip压栈计算出来的，它们之间差了两个字节。
为了证明我以上判断的准确性，我将上面的C语言程序和汇编程序修改后，编译连接成一个完整的程序，看看它究竟能否正确运行。如下图：
C语言程序修改很简单，就是去掉了display_str函数的实现，只保留声明。汇编代码如下图：
汇编语言的更改包含以下几个地方：将display_str函数导出，将pushw %bp改为pushl %ebp，同时修改获取参数的位置。编译、连接、运行程序的指令如下：
可以看到“Hello world from C language”没有正确显示出来。上面的命令都是前面用过的，不需要多解释，唯一不同的是使用C语言写的程序多了一个.rodata段，所以在objcopy的时候需要把这个段也包含进来。
由于Ｃ语言生成的函数框架都是从0x8(%ebp)开始取参数，它认为0x0(%ebp)是old ebp，0x4(%ebp)是%eip，而事实上使用16位的call指令调用函数后，0x4(%ebp)中是%ip而不是%eip，所以要从 0x6(%ebp)开始取参数。我们不可能修改C语言生成的函数框架，只能看看能否将16位的call改成32位的call。
办法当然是有的，那就是不使用.code16，而使用.code16gcc。.code16gcc和.code16不同的地方就在于它生成的汇 编代码在使用到call、ret、jump等指令时，都生成32位的机器码，相当于calll，retl，jumpl。这也是.code16gcc 叫.code16gcc的原因，因为它就是配合GCC生成的函数框架使用的。
下面再来修改代码，C语言代码修改很简单，只需要将.code16改成.code16gcc即可，如下图：
通过反汇编，可以看到它使用了32位的calll和retl，如下图：
汇编程序的修改主要是将.code16改为.code16gcc，然后手动将callw改成calll，将retw改成retl，如下图：
最后，编译连接，拷贝到freedos.img，运行虚拟机，查看运行效果，如下图：
大功告成，运行效果如上图。
总结：
编写运行于x86实模式下的16位代码是一个很复古的话题，编写能在DOS下运行的Plain Binary可执行文件是一个更复古的话题。以往，凡是需要使用x86的16位实模式的时候，作者都喜欢用NASM来编程。比如《30天自制操作系统》、 《Orange's 一个操作系统的实现》、《x86汇编语言——从实模式到保护模式》等书籍都以NASM汇编器和Intel汇编语法作为示例。而且他们都是在进入32位保护 模式后，才让汇编语言和C语言共同工作。
我用Linux操作系统，所以我就是想不管是写32位代码，还是16位代码，都能使用GCC和GNU AS。我还想即使是在16位模式下，也能尽量少用汇编语言，多用C语言。经过努力，有了上面的文章。使用GCC和GNU Binutils编写运行于x86实模式的16位代码的过程如下：
1. 如果只用汇编语言编写16位程序，请使用.code16指令，并保证只使用16位的指令和寄存器；如果要和C语言一起工作，请使用.code16gcc指 令，并且在函数框架中使用pushl，calll，retl，leavel，jmpl，使用0x8(%ebp)开始访问函数的参数；很显然，使用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处执行，所以使用ld连接时需指定-Ttext 0x100选项；引导扇区的代码会被加载到0x7c00处执行，所以使用ld连接时需指定-Ttext 0x7c00选项。
4. 使用gcc、as、ld生成的程序默认都是ELF格式，而在DOS下运行的.com程序是Plain Binary的，在引导扇区运行的代码也是Plain Binary的，所以需要使用objcopy将ELF文件中的代码段和数据段拷贝到一个Plain Binary文件中，使用-O binary选项； Plain Binary文件也可以反汇编，在使用objdump时需指定-b binary选项。
原文发布时间：2014-09-22
本文来自云栖合作伙伴“linux中国”