源文件到可执行文件流程
编译：.c 文件变成 .s 汇编文件
汇编：.s 文件变成 .o 可重定位的目标文件
链接：一个或多个.o 文件变成一个可执行文件
ELF 文件和 BIN 文件的区别
BIN文件是直接的二进制文件，内部没有地址标记。bin文件内部数据按照代码段或者数据段的物理空间地址来排列。一般用编程器烧写时从00开始，而如果下载运行，则下载到编译时的地址即可。
在 Linux OS上，为了运行可执行文件，他们是遵循ELF格式的，通常gcc -o test test.c，生成的test文件就是ELF格式的，这样就可以运行了，执行elf文件，则内核会使用加载器来解析elf文件并执行。
在Embedded中，如果上电开始运行，没有OS系统，如果将ELF格式的文件烧写进去，包含一些ELF文件的符号表字符表之类的section，运行碰到这些，就会导致失败，如果用objcopy生成纯粹的二进制文件，去除掉符号表之类的section，只将代码段数据段保留下来，程序就可以一步一步运行。
elf文件里面包含了符号表等。BIN文件是将elf文件中的代码段，数据段，还有一些自定义的段抽取出来做成的一个内存的镜像。并且elf文件中代码段数据段的位置并不是它实际的物理位置。他实际物理位置是在表中标记出来的。
ELF 文件格式详解
ELF文件格式是一个开放标准，各种UNIX系统的可执行文件都采用ELF格式，它有三种不同的类型：
可重定位的目标文件（Relocatable，或者Object File）
可执行文件（Executable）
共享库（Shared Object，或者Shared Library）
符号表机制（readelf -s XXX）
符号表保存了程序实现或使用的所有全局变量和函数，如果程序引用一个自身代码未定义的符号，则称之为未定义符号，这类引用必须在静态链接期间用其他目标模块或者库解决，或在加载时通过动态链接解决
ELF文件格式提供了两种不同的视角，在汇编器和链接器看来，ELF文件是由Section Header Table描述的一系列Section的集合，而执行一个ELF文件时，在加载器（Loader）看来它是由Program Header Table描述的一系列Segment的集合。
左边是从汇编器和链接器的视角来看这个文件，开头的ELF Header描述了体系结构和操作系统等基本信息，并指出Section Header Table和Program Header Table在文件中的什么位置，Program Header Table在汇编和链接过程中没有用到，所以是可有可无的，Section Header Table中保存了所有Section的描述信息。右边是从加载器的视角来看这个文件，开头是ELF Header，Program Header Table中保存了所有Segment的描述信息，Section Header Table在加载过程中没有用到，所以是可有可无的。注意Section Header Table和Program Header Table并不是一定要位于文件开头和结尾的，其位置由ELF Header指出，上图这么画只是为了清晰。
我们在汇编程序中用.section声明的Section会成为目标文件中的Section，此外汇编器还会自动添加一些Section（比如符号表）。Segment是指在程序运行时加载到内存的具有相同属性的区域，由一个或多个Section组成，比如有两个Section都要求加载到内存后可读可写，就属于同一个Segment。有些Section只对汇编器和链接器有意义，在运行时用不到，也不需要加载到内存，那么就不属于任何Segment。
目标文件需要链接器做进一步处理，所以一定有Section Header Table；可执行文件需要加载运行，所以一定有Program Header Table；而共享库既要加载运行，又要在加载时做动态链接，所以既有Section Header Table又有Program Header Table。
下面用readelf工具读出可重定位的目标文件max.o的ELF Header和Section Header Table，然后我们逐段分析。
接下来我们来看Section Header Table格式
从Section Header中读出各Section的描述信息，其中.text和.data是我们在汇编程序中声明的Section，而其它Section是汇编器自动添加的。Addr是这些段加载到内存中的地址（我们讲过程序中的地址都是虚拟地址），加载地址要在链接时填写，现在空缺，所以是全0。Off和Size两列指出了各Section的文件地址，比如.data从文件地址0x60开始，一共0x38个字节，回去翻一下程序，.data中定义了14个4字节的整数，一共是56个字节，也就是0x38个。根据以上信息可以描绘出整个目标文件的布局。
这个文件不大，我们直接用hexdump或者使用010 Editor工具把目标文件的字节全部打印出来看。
.shstrtab和.strtab
.shstrtab和.strtab这两个Section中存放的都是ASCII码：
见.shstrtab中保存着各Section的名字，.strtab中保存着程序中用到的符号的名字。每个名字都是以' '结尾的字符串。
我们知道，C语言的全局变量如果在代码中没有初始化，就会在程序加载时用0初始化。这种数据属于.bss段，在加载时它和.data段一样都是可读可写的数据，但是在ELF文件中.data段需要占用一部分空间保存初始值，而.bss段则不需要。也就是说，.bss段在文件中只占一个Section Header而没有对应的Section，程序加载时.bss段占多大内存空间在Section Header中描述。在我们这个例子中没有用到.bss段，以后我们会看到这样的例子。
.rel.text和.symtab
我们继续分析readelf输出的最后一部分，是从.rel.text和.symtab这两个Section中读出的信息。
.rel.text告诉链接器指令中的哪些地方需要重定位，我们在下一节讨论。
.symtab是符号表。Ndx列是每个符号所在的Section编号，例如data_items在第3个Section里（也就是.data），各Section的编号见Section Header Table。Value列是每个符号所代表的地址，在目标文件中，符号地址都是相对于该符号所在Section的相对地址，比如data_items位于.data段的开头，所以地址是0，_start位于.text段的开头，所以地址也是0，但是start_loop和loop_exit相对于.text段的地址就不是0了。从Bind这一列可以看出_start这个符号是GLOBAL的，而其它符号是LOCAL的，GLOBAL符号是在汇编程序中用.globl指示声明过的符号。
.text节
通过使用objdump工具可以把程序中的机器指令进行反汇编（Disassemble），得到其汇编代码
可执行文件
先看可执行文件header的变化
在看section header的变化
.text和.data的加载地址分别改成了0x08048074和0x0804 90a0。.bss段没有用到，所以被删掉了。.rel.text段就是用于链接过程的，链接完了就没用了，所以也删掉了。
在看多出来的两个program header
多出来的Program Header Table描述了两个Segment的信息。.text段和前面的ELFHeader、Program Header Table一起组成一个Segment（FileSiz指出总长度是0x9e），.data段组成另一个Segment（总长度是0x38）。VirtAddr列指出第一个Segment加载到虚拟地址0x0804 8000（注意在x86平台上后面的PhysAddr列是没有意义的），第二个Segment加载到地址0x0804 90a0。Flg列指出第一个Segment的访问权限是可读可执行，第二个Segment的访问权限是可读可写。最后一列Align的值0x1000（4K）是x86平台的内存页面大小。在加载时要求文件中的一页对应内存中的一页，对应关系如下图所示。
这个可执行文件很小，总共也不超过一页大小，但是两个Segment必须加载到内存中两个不同的页面，因为MMU的权限保护机制是以页为单位的，一个页面只能设置一种权限。此外还规定每个Segment在文件页面内偏移多少加载到内存页面仍然偏移多少，比如第二个Segment在文件中的偏移是0xa0，在内存页面0x0804 9000中的偏移仍然是0xa0，所以是从0x0804 90a0开始，这样规定是为了简化链接器和加载器的实现。从上图也可以看出.text段的加载地址应该是0x0804 8074，也正是_start符号的地址和程序的入口地址。
原来目标文件符号表中的Value都是相对地址，现在都改成绝对地址了。此外还多了三个符号__bss_start、_edata和_end，这些是在链接过程中添进去的，加载器可以利用这些信息把.bss段初始化为0。
再看一下反汇编的结果：
