1. Linux下的二进制可执行文件。
如果世界很简单,那么二进制可执行文件也应该很简单,只包括CPU要执行的指令就可以了。可惜,世界并不简单……。Linux下的二进制可执行文件(以下简称可执行文件),也并不是只包括了指令,还包括了很多其他的信息,比如,执行需要的数据,重定位信息,调试信息,动态链接信息,等等。 所有这些信息都按照一个预定的格式组织在一个可执行文件里面。Linux下叫ELF可执行文件。
举一个最简单的例子,假设有下面这个程序:
int main()
{
return 0;
}
这个连“Hello World”都不能打印的程序,自然是什么都做不了。当然,如果只是把这个文件保存为文本文件,是无论如何也执行不了得。还需要两个重要的步骤:编译和链接,才能把它转换为可执行的ELF格式。
先来看看编译,也就是把C语言翻译成机器语言的过程。很简单,用下面的命令:
gcc -c test.c -o test.o <假设源文件名为test.c>
-c 参数告诉gcc,我们只需要编译这个文件,不需要连接。这样就会生成一个test.o文件。这个文件包含了上面源程序翻译后的机器指令和其他一些信息。这个test.o也属于ELF格式。如何看test.o里面的内容,可以用objdump命令:
objdump -x test.o
会有类似下面的输出:
test.o: file format elf32-i386
test.o
architecture: i386, flags 0x00000010:
HAS_SYMS
start address 0x00000000
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000000a 00000000 00000000 00000034 2**
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 00000000 00000000 00000040 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000040 2**2
ALLOC
3 .comment 0000002b 00000000 00000000 00000040 2**0
CONTENTS, READONLY
4 .note.GNU-stack 00000000 00000000 00000000 0000006b 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 test.c
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 l d .note.GNU-stack 00000000 .note.GNU-stack
00000000 l d .comment 00000000 .comment
00000000 g F .text 0000000a main
test.o 主要包含了文件头和节。"节“是ELF文件的重要组成部分,一个节就是某一类型的数据。objdump的-x参数会打印出test.o中所有的节,也就是上面的"Sections". 其中.text节包含了可执行代码,.data节包含了已经初始化的数据,.bss节包含了未初始化数据。其他的节先忽略掉(其实是因为我也了解不多⋯⋯)
如果要看看test.o是不是包含源文件的编译结果, 可以将其反汇编查看。使用objdump -d 命令。 默认情况下,该命令只返回目标文件的可执行部分,在这里就是.text节。 objdump -d test.o 得到的结果如下:
test.o: file format elf32-i386
Disassembly of section .text:
00000000 <main>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: b8 00 00 00 00 mov $0x0,%eax
8: 5d pop %ebp
9: c3 ret
可以看见这里就是一些栈的操作,没有做什么事情。当然,源码里面确实也没做什么事情。这个.o文件还不能执行,还需要经过链接。通常,我们可以用gcc一步完成编译链接过程,也就是我们最常用的:
gcc test.c -o test
如果再次用objdump -d 反编译生成的test文件:
objdump -d test
额……会发现多了一堆东西。这是因为,c程序通常都是链接到c运行库的。在main函数执行前,c运行库需要初始化一些东西。这也说明,main()并不是程序的真正入口点。真正的入口点可以用objdump -f 查看test的文件头:
test: file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x080482e0
start address就是开始执行的入口点, 这个地址对应反汇编中的"_start"符号。
那么可以让程序不链接到c运行库么?当然可以,可以用ld手工链接:
ld test.o -e main -o test
“-e main”告诉ld链接器用main函数作为入口点。这里也可以看出,一个程序的入口函数,不一定是main,可以是任意函数。再次反汇编刚生成的可执行文件,就会发现,已经没有c运行库的代码了。
可是,如果试着执行刚刚生成的程序,竟然会得到一个段错误……这是因为,没有了c运行库,main函数返回之后,程序执行到不确定的地方。而如果通过c运行库调用main(),返回后会到c运行库里面,会调用相关函数来结束进程。
2. 裸机程序的实现
所谓裸机程序,也就是没有操作系统支持,芯片上电后就可以开始执行的程序,就和单片机程序一样。不知道用”裸机程序“这个名称是否合适,不过也找不到其他的名字了。
裸机程序与上面的ELF可执行文件有什么不同,首先很明显一点,ELF文件是需要有一个解析器,或者叫装载器的, 这个装载器负责解析文件头,将其中的节都映射到进程空间,如果有重定位,要先完成重定位,如果有动态链接库,还要加载动态链接库,完成种种初始化之后,才跳转到程序的入口点开始执行程序。而所有这些,都是由OS支持的。而对于一个ARM芯片来说,他可不知道什么ELF,重定位和动态链接。ARM只知道上电后,寄存器复位到初始值,PC寄存器为0x00000000,也就是从内存地址为0的地方开始取指令执行,其它的一概不知道,也不管。
这么说来,要弄出一个裸机程序,其实也不难,只要我们编译上面的源代码,然后想办法把它加载到内存0开始的地方就可以了。事实,也确实是这样。只是有几个小问题要先解决掉:
1.从0