ARM链接器可以把编译(或汇编)生成的多个目标文件和所需要的多个库文件链接在一起,生成可执行的ELF格式的输出文件。

在链接过程中,如果在链接器的输入文件中同时包含ARM代码和Thumb代码,链接器可以自动为实现不同代码之间的链接生成一个veneer文件。该文件用来帮助目标处理器实现两种不同状态之间的转换,并可以实现长跳转。链接器还可以为指令代码段和或数据段指定在目标存储器中的位置。

1  链接的一般概念
1.1  链接器的输入和输出
1、目标文件和映像文件

链接器的输入就是编译器的输出。编译器编译后生成的文件称为目标文件,是ELF(Executable Linkable Format)格式。ELF格式目标文件是一个非文本文件,一般包含指令代码和编译信息两部分,提供给链接器使用。

目标文件经过链接器链接生成的文件称为映像文件,仍然是ELF格式。之所以称为映像文件,是因为文件中程序之间的位置关系与实际存储时的地址关系是对应的,程序代码是实际储存后的代码的一个“映像”。一般情况下,存储到程序存储区的程序都是从地址0x0000开始的,但映像文件的开始地址可以不是从0x0000开始,在ADS系统总默认是0x8000。

目标文件和映像文件都是ELF格式的,它们之间最主要的区别在于:目标文件中代码和符号的地址是不确定的,而映像文件中代码和符号的位置必须是确定的。

2、文件和段

文件是计算机操作的基本单位,而段则是链接器操作的基本单位。一个文件中可以包含一个或多个段。对于链接器来说,它不关心有多少个输入文件,而只关心有多少个输入段。

链接器的输入段其来源可以有两种:一种是来自源文件中的段;另一种是来自库中的段。这些段有三种属性:只读(RO)段、可读写(RW)段、初始化为零(PI)段。

链接器的输出是一个可执行的映像文件,包含一个或多个段。这些在镜像文件中的段叫输出段,也有三种属性:只读(RO)段、可读写(RW)段、初始化为零(PI)段。

3、映像文件的结构

(1) 映像文件由一个或多个域组成

映像文件中的域,就是存放映像文件的一个存储区。一个映像文件占用几个存储区,主要看映像文件的结构和目标存储器的组成。如果映像文件不大,一般情况下自用一个存储区;如果系统比较复杂,而文件又很大,一般把只读属性的代码和可读/写属性的数据分开存储。

(2) 每个域包含一个或多个输出段

每个域可以包含一个、两个或三个输出段,主要看域的存放位置和对输出段的要求,也和存储器的特性有关。

(3)每个输出段包含一个或多个输入段

链接器把属性相同的输入段按照一定的顺序组织在一起,形成输出段。属性相同的输入段,它们在系统中的作用相近,这样组成的输出段便于存储和管理。

(4)每个输入段都都可以包含代码和数据

输入段可以包含代码和数据,如在一个代码段后面定义一个数据缓冲区。但是这样的代码和数据只能有相同的属性,一般定义为只读属性。所以,如果数据需要可读/写,就不能和代码处于同一段内。

1.2  映像文件的加载和执行
1、加载域和执行域

映像文件可以有两种地址:加载地址和执行地址。加载地址就是文件在存储器中的存储地址,执行地址就是文件在运行时的地址。文件加载的存储区叫加载域,文件运行的存储区叫执行域。例如,为了提高速度,要把执行的程序从ROM存储区移到高速缓冲区之后再执行,此时,加载地址就不再是执行地址了。

2、位置无关

3、映像文件的入口点

映像文件有两种入口点:初始入口点和普通入口点。

l 映像文件的初始入口点存储在ELF格式的文件头中。每个映像文件只能有一个初始入口点。它必须满足两个基本条件:必须总是位于映像文件的可执行地址范围内;这个地址范围不能被覆盖,且加载地址和执行地址总是同一个地址。初始入口点可以是普通入口点。

l 在汇编语言源程序中,由ENTRY伪指令定义的入口点是普通入口点,并可以定义多个入口点。这些入口点可以作为中断处理程序的入口。

1.3  输入段在映像文件中的排列顺序
1、为输入段指定地址的方法

l 在命令行和图形方式中使用和地址有关的选项,常用的可以影响地址分配的选项有:

-ro-base、-rw-base、-split、-ropi、-rwpi。

l 在命令行和图形方式中使用为输入段指定位置的选项,包括:

-entry location、-first section-id、-last section-id。

l 当目标系统和映像文件很复杂时,使用scatter格式文件,可以为每个输入段指定详细地址信息。

2、输入文件的排序规则

在默认情况下,链接器按照下面的顺序组织输入段:

l 只读代码段

l 只读数据段

l 可读写代码段

l 非零初始化的数据段

l 零初始化的数据段

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/formerman/archive/2009/07/26/4382034.aspx