ARM系统基本文件格式

 这里所说的ARM系统基本文件格式,都是在基于ARM的嵌入式系统开发中常会碰到的文件格式。  

 ARM系统基本文件格式有三种:
1) BIN,平板式二进制格式,一般用于直接烧写到Flash中,也可以用于加载到monitor程序中。
2) ELF,EXECUTABLE AND LINKABLE FORMAT,一种通用的OBJECT文件格式,一般由GNU COMPILER COLLECTION (GCC)产生。
3) AXF,BIN格式的扩展版,主体部分同BIN,在文件头和尾加入了调试用的信息,用于AXD。

本文主要讨论BIN与ELF。
    首先说明,ELF格式是一种OBJECT文件格式。一般OBJECT文件都可以分成三类:可重定位OBJECT文件,可执行OBJECT文件,共享OBJECT文件。ELF格式文件也可以分成这三种。
    首先说说可重定位OBJECT文件。这种OBJECT文件一般由GCC中的ASSEMBLER(as)产生(请不要认为GCC只是编译器),里面除了二进制的机器代码,还有一些可用于进行重定位的信息。它主要是作为LINKER(ld)的输入,LINKER将跟据这些信息,将需要重定位的符号重定位,进而产生可执行的OBJECT文件。ELF格式的可重定位OBJECT文件由header与section组成。
    Header 包括ELF header 与 section header. ELF header 位于文件的头部,用于存储目标机器的架构,大小端配置,ELF header大小,object文件类型,section header 在文件中的偏移,section header    的大小,section header 中的项目数等信息。Section header 则定义了文件中每个section 的类型,位置,大小等信息。Linker就是通过查找ELF header,找到section header 的入口,再在section header 中找到相应的section 入口,进而定位到目标section 的。
    Section 包括 
.text    :经过编译的机器代码。
.rodata  :只读的数据,例如printf(“hello!”)中的字符串hello。
.data    :已初始化的全局变量,局部变量将在运行时被存放在堆栈中,不会在.data或 .bss段中出现。
.bss     :未初始化的全局变量,在这里只是一个占位符,在object文件中并没有实际的存储空间。
.symtab  :符号表,用于存放程序中被定义的或被引用到的全局变量和函数的信息。
.rel.text  :一个保存着一系列在.text中的位置的列表。这些位置将在linker把这个文件与其它object文件合并时被修改,一般来说,这些位置都是保存着一些引用到全局变量或者外部函数的指令。引用局部变量或者本地函数的指令是不需要被修改的,因为局部变量和本地函数的地址一般都是使用PC相对偏移地址的。需要注意的是,这个section 和下面的.rel.data在运行时并不需要,生成可执行的ELF object文件时会去掉这个section。
.rel.data :保存全局变量的重定位信息。一般来说,如果一个全局变量它的初始化值是另一个全局变量的地址,或者是外部函数的地址,那么它就需要被重定位。
.debug  :保存debug信息。
.strtab  : 一个字符串表,保存着.symtab和.debug ,和各个section的名字。.symtab,.debug 和section table里面,凡是保存name的域,其实都是保存了一个偏移值,通过这个偏移值在这个字符串表里面可以找到相应得字符串。
    下面仔细讨论一下.symtab:
    每一个可重定位的object文件,都会有一个.symtab。这个符号表保存了在这个object文件中所有被定义的和被引用的符号。当源程序是C 语言程序时,.symtab 中的符号直接来源于C编译器(cc1)。这里所说的符号主要有三种:
1) 在这个object文件中被定义的可以被其他object文件全局符号。在C语言源程序中,主要就是那些非静态(没有static 修饰的)的全局变量和非静态的函数。在ARM汇编语言中,就是那些 被EXPORT 指令导出的变量。
2) 在这个object文件中引用到,但是在其他文件中定义的全局变量。在ARM汇编语言中就是通过IMPORT命令引入的变量
3) 本地变量。本地变量只在本object文件内可见。这里的本地变量指的是连接器本地变量,应该和一般的程序本地变量作区别。这里所指的本地变量,包括用static 修饰的全局变量,object文件中section名称,源代码文件名称。一般意义上的本地变量,是在运行时由系统的运行时环境管理的,linker并不关心。
    每个符合上面条件的符号在.symtab文件中都会有一个数据项。这个数据项的数据结构是:

Typedef struct{
    int name;//符号名称,其实就是.strtab的偏移值
    int value;//在section中的位置,以相对section地址的偏移表示
    int size;//大小
    char type;//类型,一般是数据或函数
    char binding;//是本地变量还是全局变量
    char reserved;//保留的位
        char section;//符号所属的section。可选有:.text(用数字1代表),.data(用数
                            //3代表),ABS(不应被重定位的符号),UND(在本object文件
                            //中未定义的符号,可能在别的文件中定义),COM(一般的未初//始化的变量符号)。
}ELF_sym

    现在假设组成应用的各个模块都已经被汇编,构建出了可重定位的object文件。这些object的结构都是一样的,有各自的.text, .data section, 有各自的.symtab. GCC下一步要做的就是使用linker (ld),把这些object文件,加上必要的库连接成具有绝对运行时地址的可执行文件,就是可执行的ELF格式的文件。
    Linker 的连接动作可以分为两部分:
1) 符号解析。确定引用符号的指向。
2) 符号重定位。合并section,    分配运行时环境地址,引用符号重定位。
    符号解析:
    在一个object文件中,有指令定义了符号,也有指令引用了符号。可能存在这样一种情况,一个被引用到的符号,有多重的定义。符号解析的作用就是确定,在这个object文件中,一个符号引用真正引用的是哪个符号。
    在编译的时候,除了在本文件中定义的全局变量会由编译器生成一个符号表项之外,当发现一个被引用到的符号在本文件中并没有被定义,编译器也会自动产生一个符号表项,把确定这些引用的工作留给linker。汇编器在汇编时将读取这些符号表项,生成.symtab。在读取的过程中,如果发现有在无法确定的符号引用项,汇编器会为这些符号额外生成一个数据项,称作重定位数据项,存放于rel.text或rel.data section中,交由linker确定。下面是重定位数据项(relocation entry)的数据结构:

Typedef struct{
    int offset;//指明需要被重定位的引用在object中的偏移,实际上就是需要被重定位的引用
                   //在object中的实际位置
    int symbol;//这个被重定位的引用真实指向的符号
    int type;//重定位类型:R_ARM_PC24:使用24bit的PC相对地址重定位引用
          //R_ARM_ABS32:使用32bit绝对地址重定位引用
}Elf32_Rel

    Linker 需要解析的,就是那些被生成了重定位数据项的引用。Linker将根据C语言定义的规则,对于每一个重定位数据项,在输入的各个object文件中查找适合的符号,把这个符号填入symbol项中。但是由于还不知道这个符号的真实地址,所以现在就算知道了引用的真实指向,但我们还是不能确定这个引用指向的地址。
    符号重定位:
    符号重定位用来解决上面的问题。Linker首先进行section 的合并。Linker合并object文件的过程很简单,一般就是相同属性的section合并,例如不同object文件的.text section 将被合并成一个.text。同样,.symtab section也被合并成一个.symtab。这里面涉及到两个问题:
1) 各个object文件合并的顺序。这个问题涉及到最终指令和符号的运行地址。最为重要的是,究竟是哪个section排在最前头?在ARM RAW 系统得开发过程中,这个最为重要。ARM系统CPU上电后,系统会自动的从0x00000000地址取指令并执行,这个地址上映射着存储器。这个动作是不可编程的。所以排在最前面的section一定要包含有程序的入口点,否则系统无法正常运行。
2) 输入段与输出端之间的对应关系。理论上,任何section,都可以被随意的映射到一个输出段中。一个.data section是可以与一个.text section 组成输出一个.text的。当然这样的动作毫无意义。我们必须告诉linker使用那些section作为输入,产生一个输出section.
    以上这两个问题,都是通过一个称为连接脚本的文件控制的。Linker通过读取连接脚本,来决定section 从输入到输出的映射,设置程序的入口点,设置哪个section应该在整个可执行文件的头部等问题。
    连接脚本还有另外一个作用,那就是指定每个section的地址。在section 合并完成后,linker将跟据.symtab,对符号进行统一的编址,分配一个绝对的运行时地址。这个地址是以section地址作为基地址的。假设.text section的地址是0x00000000,那么.text里面的符号将以0x00000000这个地址作为基准地址。指定section地址的工作也是由连接脚本完成。在嵌入式开发中常见的在编译工程时需指定的text_base, data_base等参数,最后会被加入到连接脚本中,从而完成section的地址分配。
    以上两步完成后,linker 执行引用符号重定位操作。Linker遍历.rel section (包括.rel text 和 .rel data),对于其中的每个数据项,根据symbol域到.symtab 中查出相应的引用的真实地址(经过上面的地址分配,现在.symtab里面的符号都具有绝对的运行地址),再根据offset域提供的偏移,将这个地址填入相应的位置上。
    至此,符号重定位工作全部完成。Linker删除用于保存重定位信息的rel.text和rel.data section,加入一个segment header和 一个.init section。生成可执行的ELF格式的object文件。
    Segment header保存了用于操作系统内存映射的信息。.init section 包含了一个_init 的函数。程序加载时,操作系统的程序加载器通过读取segment header,将程序加载到用户内存空间,并根据segment header里面映射信息,分别将.text 段和.data段映射到适当的地址上。然后再调用.init中的_init函数,完成初始化工作。
    由于ELF文件具有通用性强的优点,现在流行的开发模式是,先通过编译工具生成ELF文件格式的可执行文件,在使用外部工具,抽离出ELF文件中的相应部分,生成BIN文件。例如著名的GNU bootloader U-Boot,就采用了这种做法,编译器工具集是GCC,BIN生成工具是elf2bin。ARM公司著名的开发环境ADS,虽然使用的是自家的armcc,和armcpp编译器,但他们的工作方式却是与GNU GCC如出一辙。

你可能感兴趣的:(ARM系统基本文件格式)