简述
早前Keil被ARM收购,而目前比较主流的嵌入式系统的IC都是ARM架构的,因此许多嵌入式工程开发环境是Keil,一些比较复杂的情况下需要根据自己的需要划分memory空间,因此对Keil中链接脚本的内容值得学习一番。下面的介绍都是基于ARM Compiler armlink v6.4 Release(2016.2.24更新版本)进行的。
armlink相关介绍
基本特性
Linker的功能就是将编译生成的各个中间文件作为输入,产生链接后的可执行文件。
- 支持多种格式的可执行文件输出(比如binary, hex, axf等);
- 可以链接A32, T32或A64代码;
- 自动选择合适的C或C++库进行链接;
- 可以自定义将code和data放在memory map的对应位置,通过链接时输入命令或者使用scatter file的形式进行;
- RW data压缩占用最小的ROM size;
- 优化未用的sections;
- 在链接输出文件中置入调试信息;
- 产生静态的调用图,并列出stack的用量;
- 输出文件中置入symbol table;
- 输出文件中显示code和data size;
link command
armlink options input-file-list
输入项 | 说明 |
---|---|
options | Linker command-line options |
input-file-list | A space-separated list of objects, libraries, or symbol definitions (symdefs) files |
关于options输入项,Keil列出了上百种,方便配置各项link参数。
link过程
* 从输入文件解析符号;
* 从库中抽取对象模块,以满足一些符号需求;
* 移除未使用到的sections;
* 将重复的共用的代码,数据,调试sections进行优化;
* 将输入sections进行分类,将相似属性与名字的sections进行整合成为连续的块;
* 根据分组和提供的划分信息组织对象放入memory区域;
* 分配地址给可重定位的值;
* 产生可执行image。
链接模式
链接模式(Linking Model)是因命令参数和memory map不同而使用的链接器的不同行为模式。
链接模式 | 说明 |
---|---|
Bare-metal | 目标无关,可以使用自己的OS, memory map, app code创建image,一些有限制性的动态链接也支持。可以指定额外的选项 |
Bare-metal Position Independent Executables(PIE) | 不需要指定地址,可以在任何适合的地址执行,所有对象和库都必须是位置无关的 |
Partial linking | 已经链接过的部分ELF文件作为输入,继续进行链接 |
BPABI | 支持类似DLL方式 |
Base Platform | 为BPABI的支持scatter-loading的扩展 |
Image的结构
ARM ELF image由sections, regions, segments组成。
ELF object file view(linker input)
从链接输入文件的角度看,ELF object file可以是如下类型:
ELF object file | 说明 |
---|---|
可重定位文件 | 应当就是编译后的文件,可以重定位 |
共享对象文件 | 包含了code和data的共享对象文件 |
Linker View
从链接器的角度看,有两种类别的地址:
地址类别 | 说明 |
---|---|
Load Address | Linker期望外部加载器之类的从ELF文件拷贝fragment的位置/地址, 可能和fragment实际执行的地址并不一样 |
Execution Address | Linker期望fragment程序执行期间的实际地址 |
如果一个fragment是位置独立的或可重定位的,那执行期间它的执行地址可以变化。
ELF image file view(linker output)
ELF image file view由程序segment和output sections组成:
组成部分 | 说明 |
---|---|
Load region | 一个Load region对应一个程序片段(program segment) |
Execution region | 包含了RO, RW, XO, ZI其中一个或以上的output sections |
一个或多个execution regions组成一个Load region。
各个部分进一步说明
部分 | 说明 |
---|---|
Input section | 从链接输入文件中解析出的独立section,包含code(RO),初始化了的data(RW),未初始化但描述了一段memory(XO),在image能执行前必须设置为0的部分,一般是在该output section给出描述,实际空间是在执行时分配的(ZI) |
Output section | 将有相同RO,RW,XO,ZI属性的input sections组成起来,被linker整合为连续的内存空间 |
Region | 一个region可包含多达4个output sections,output sections在region中的位置为XO–>RO–>RW–>ZI,一个region一般映射到物理memory设备(ROM,RAM,Peripheral),也可能通过scatter-loading改变output sections的顺序 |
Program segment | 一个程序片段对应一个load region(包含execution regions),程序片段包含text和data信息 |
注:XO memory只支持ARMv7-M和ARMv8-M架构。
image结构的加载时视图以及运行时视图
为何之前提到的Load Address和Execution Address可能会不同呢,因为在load(bootloader)时是将image regions放到系统的memory map,但是在程序执行时,memory中region的位置可能发生改变。
在执行image前,有时候可能需要将一些regions移到memory的可执行地址,并创建ZI output sections。例如RW data可能需要从其处于ROM的load address拷贝到处于RAM中的execution address。
视图 | 说明 |
---|---|
Load view | 程序下载到memory,但程序尚未运行 |
Execution view | 程序开始运行后 |
所以Load Address和Execution Address的不同就是因为在程序启动时,会有memory搬移的动作而导致地址发生变化。
常见image视图示例
OS bootloader或桌面系统:
对应链接command:
armlink --cpu=8-A.32 --ro_base 0x8000
一般没有特别通过armlink指定,regions中output sections的排序是XO–>RO–>RW–>ZI的,这里只指定了ro_base,即RO地址指定了,RW,ZI会自动链接到其后面。
上面这里没有XO section,如果有的话,ro_base是指定的XO section的地址,RO,RW,ZI会连续接在其后面。
Embedded系统
对应的链接command:
armlink --cpu=8-A.32 --ro_base 0x0 --rw_base 0xA000
注意,如果有XO section的话,和上图一样的处理。另外,execution address和load address不同的话,搬移时原则是execution region不能和load region有重合。
更加复杂点的情况
对应的链接command:
armlink --cpu=8-A.32 --split --ro_base 0x8000 --rw_base 0xE000