Linker Script，LMA，VMA实例分析

以前在学ld的script时两个比较重要的概念，即指定一个输出section的lma和 vma(分别是load memory address和virtual memory address)，vma的作用是很明显地，就是决定run time address嘛，但lma有什么用呢？恩，对运行在linux这样的操作系统上面的应用程序来说，是没什么用的，毕竟应用程序都是被'load'到虚拟 地址空间中。但是在嵌入式底层firmware, bootloader开发来说，这个关键字不再打酱油。

 

看下面这么一段代码，汇编：

1. .section .text  
2. _symbol_in_text:  
3. mov $1, %eax  
4. .section .data  
5. _symbol_in_data:  
6. .long 0x90909090  

简单得不能再简单了，定义了两个段，.text和.data，.text里面就一条指令，.data里面也只有一个字。

先编译成可重定向的.o目标文件：

1. gcc -o xxx.o -c xxx.S  

接着用ld将其链接成可运行文件，这里其实只有一个目标文件参与链接，所以说链接其实是不对的，ld只是做做重定向或者叫定址的工作而已，外加在elf文件中产生描述文件的segment和section的信息等。

链接时首先提供一个最简单的ld script:

1. OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")  
2. OUTPUT_ARCH(i386)  
3. SECTIONS  
4. {  
5.         .text 0x5000                    : { *(.text) }  
6.         .data 0x8000                    : { *(.data) }  
7. }  

在上面这个ld script中只定义了vma；根据ld的规则：如果没有用AT指令定义lma的话，那么lma默认等于vma。

这 里为什么两个段(.data和.text)的vma不一样？试想在嵌入式系统中是不是会遇到这种情况，即Flash(Rom)空间较大，Ram空 间相对较小，于是我们只希望让数据装载进Ram空间，代码就直接运行在Flash(Rom)中。比如Flash(Rom)的起始地址0x5000，Ram 的起始地址0x8000，所以这两个段的vma就必须对应到相应Region的起始地址上。不然会怎么着？不是跑飞就是读写的数据找不到。

链接：

1. ld ./lma_vma.o -T ./lma.equal.vma.lds  

生成a.out可执行文件。

注 意，这个a.out是‘可执行’的elf文件。对于bootloader或者firmware来说，一般是直接把一个binary文件 ‘burn’到板子上的。把elf文件剥离成一个binary文件，在万能的gnu tool帮助下，非常简单，一个objcopy便可搞定：

1. objcopy -O binary ./a.out  

好了，用file看一下文件类型：

1. ./a.out: COM executable for MS-DOS  

应该就是'bin'文件了。

且慢，还记得之前我们没有用AT指令指定两个段的lma么。那么，问题来了，我们先用ls -l看一下有什么异样：

1. [root@localhost ldscript_test]# ls -lh ./a.out  
2. -rwxr-xr-x 1 root root 13K 11-04 20:55 ./a.out  

文件足足有13k大小。别忘了，我们的源程序只有一条指令和一个32位的字，并且是纯数据的bin文件，为什么有这么大？

看看这个纯数据的文件里面有些啥，借助于hexdump，真相一目了然：

1. [root@localhost ldscript_test]# hexdump ./a.out  
2. 0000000 01b8 0000 0000 0000 0000 0000 0000 0000  
3. 0000010 0000 0000 0000 0000 0000 0000 0000 0000  
4. *  
5. 0003000 9090 9090  

最 开始01b8应该就是mov $1, $eax的instruction code。而0x3000位置的90909090显然就是我们定义在数据段的字了。因为链接器脚本中没有用AT指令专门为两个段指定lma，所以其lma 与vma相等，两个段相差了0x3000 bytes的长度。.text段之前没有其他段了，所以最终的bin文件中一开始就是.text段的内容，虽然只有2个字节，但仍然要过0x3000 bytes才是.data段。中间那些未知数就填0了。

这样有什么问题呢？因为我们知道0x8000已经是Ram了，难道我们要将全局数据 烧到一断电内容就消失的Ram中？并且，Flash(Rom)和 Ram之间相隔的0x3000 bytes不一定就对应实际的存储区域（比如也在Flash中），有可能根本就是hole。那么‘烧’这些0下去有可能会造成问题。

我们希望的结果是，烧写的data和text都在Flash(Rom)中，运行后再将data自搬运到Ram中。最好bin文件中两个段紧挨着，保持文件尽可能小的size。

下面的ld script在定义.data段时增加了AT指令来描述其lma，这样表示.data段的lma紧接在.text段的后面：

1. OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")  
2. OUTPUT_ARCH(i386)  
3. SECTIONS  
4. {  
5.         .text 0x5000           :  
6.         {  
7.                 *(.text)  
8.         }  
9.         .data 0x8000                : AT(ADDR(.text) + SIZEOF(.text))  
10.         {  
11.                 *(.data)  
12.         }  
13. }  

这次链接、objcopy后生成的a.out文件看一下：

1. [root@localhost ldscript_test]# hexdump ./a.out  
2. 0000000 01b8 0000 9000 9090 0090  
3. 0000009  

只有9个字节大小，里面的内容正好是一条指令加上后面的0x90909090（指令后面的两个0x00是为了4字节对齐.data的pad）

这个bin文件就可以放心的烧写到Flash(Rom)中去了。不过，将.data段搬运到Ram的代码还是得自己写的。更系统的学习ld script，请info ld。