分类： 嵌入式
2011-02-16 15:37:53
原文地址: http://blog.csdn.net/redredbird/archive/2010/11/03/5986035.aspx
以前在学ld的script时两个比较重要的概念，即指定一个输出section的lma和vma(分别是load memory address和virtual memory address)，vma的作用是很明显地，就是决定run time address嘛，但lma有什么用呢？恩，对运行在linux这样的操作系统上面的应用程序来说，是没什么用的，毕竟应用程序都是被'load'到虚拟地址空间中。但是在嵌入式底层firmware, bootloader开发来说，这个关键字不再打酱油。
看下面这么一段代码，汇编：
简单得不能再简单了，定义了两个段，.text和.data，.text里面就一条指令，.data里面也只有一个字。
先编译成可重定向的.o目标文件：
接着用ld将其链接成可运行文件，这里其实只有一个目标文件参与链接，所以说链接其实是不对的，ld只是做做重定向或者叫定址的工作而已，外加在elf文件中产生描述文件的segment和section的信息等。
链接时首先提供一个最简单的ld script:
在上面这个ld script中只定义了vma；根据ld的规则：如果没有用AT指令定义lma的话，那么lma默认等于vma。
这里为什么两个段(.data和.text)的vma不一样？试想在嵌入式系统中是不是会遇到这种情况，即Flash(Rom)空间较大，Ram空间相对较小，于是我们只希望让数据装载进Ram空间，代码就直接运行在Flash(Rom)中。比如Flash(Rom)的起始地址0x5000，Ram的起始地址0x8000，所以这两个段的vma就必须对应到相应Region的起始地址上。不然会怎么着？不是跑飞就是读写的数据找不到。
链接：
生成a.out可执行文件。
注意，这个a.out是‘可执行’的elf文件。对于bootloader或者firmware来说，一般是直接把一个binary文件‘burn’到板子上的。把elf文件剥离成一个binary文件，在万能的gnu tool帮助下，非常简单，一个objcopy便可搞定：
好了，用file看一下文件类型：
应该就是'bin'文件了。
且慢，还记得之前我们没有用AT指令指定两个段的lma么。那么，问题来了，我们先用ls -l看一下有什么异样：
文件足足有13k大小。别忘了，我们的源程序只有一条指令和一个32位的字，并且是纯数据的bin文件，为什么有这么大？
看看这个纯数据的文件里面有些啥，借助于hexdump，真相一目了然：
最开始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段的后面：
这次链接、objcopy后生成的a.out文件看一下：
只有9个字节大小，里面的内容正好是一条指令加上后面的0x90909090（指令后面的两个0x00是为了4字节对齐.data的pad）
这个bin文件就可以放心的烧写到Flash(Rom)中去了。不过，将.data段搬运到Ram的代码还是得自己写的。更系统的学习ld script，请info ld
