.lds连接脚本文件的分析
来源：互联网 发布：网络机房相关证书 编辑：程序博客网 时间：2024/06/01 08:15
对于.lds文件，它定义了整个程序编译之后的连接过程，决定了一个可执行程序的各个段的存储位置。虽然现在我还没怎么用它，但感觉还是挺重要的，有必要了解一下。
先看一下GNU官方网站上对.lds文件形式的完整描述：
SECTIONS {
...
secname start BLOCK(align) (NOLOAD) : AT ( ldadr )
{ contents } >region :phdr =fill
...
}
secname和contents是必须的，其他的都是可选的。下面挑几个常用的看看：
1、secname：段名
2、contents：决定哪些内容放在本段，可以是整个目标文件，也可以是目标文件中的某段（代码段、数据段等）
3、start：本段连接（运行）的地址，如果没有使用AT（ldadr），本段存储的地址也是start。GNU网站上说start可以用任意一种描述地址的符号来描述。
4、AT（ldadr）：定义本段存储（加载）的地址。
看一个简单的例子：（摘自《2410完全开发》）
SECTIONS {
firtst 0x00000000 : { head.oinit.o }
second 0x30000000 : AT(4096) { main.o }
} 这就是存储地址和连接（运行）地址的不同，称为加载时域和运行时域，可以在.lds连接脚本文件中分别指定。
编写好的.lds文件，在用arm-linux-ld连接命令时带-Tfilename来调用执行，如
arm-linux-ld
arm-linux-ld
arm-linux-ld
arm-linux-ld
既然程序有了两种地址，就涉及到一些跳转指令的区别，这里正好写下来，以后万一忘记了也可查看，以前不少东西没记下来现在忘得差不多了。。。
ARM汇编中，常有两种跳转方法：b跳转指令、ldr指令向PC赋值。
我自己经过归纳如下：
（1） bstep1
（2） ldrpc, =step1
（3） 此外，有必要回味一下adr伪指令，U-boot中那段relocate代码就是通过adr实现当前程序是在RAM中还是flash中。仍然用我当时的注释：
relocate:
adrr0, _start
ldrr1, _TEXT_BASE
cmpr0, r1 OUTPUT_FORMAT("elf32­littlearm", "elf32­littlearm", "elf32­littlearm")
;指定输出可执行文件是elf格式,32位ARM指令,小端
OUTPUT_ARCH(arm)
;指定输出可执行文件的平台为ARM
ENTRY(_start)
;指定输出可执行文件的起始代码段为_start.
SECTIONS
{
. = 0x00000000 ; 从0x0位置开始
. = ALIGN(4) ; 代码以4字节对齐
.text : ;指定代码段
{
cpu/arm920t/start.o (.text) ; 代码的第一个代码部分
*(.text) ;其它代码部分
}
. = ALIGN(4)
.rodata : { *(.rodata) } ;指定只读数据段
. = ALIGN(4);
.data : { *(.data) } ;指定读/写数据段
. = ALIGN(4);
.got : { *(.got) } ;指定got段, got段式是uboot自定义的一个段, 非标准段
__u_boot_cmd_start = . ;把__u_boot_cmd_start赋值为当前位置, 即起始位置
.u_boot_cmd : { *(.u_boot_cmd) } ;指定u_boot_cmd段, uboot把所有的uboot命令放在该段.
__u_boot_cmd_end = .;把__u_boot_cmd_end赋值为当前位置,即结束位置
. = ALIGN(4);
__bss_start = .; 把__bss_start赋值为当前位置,即bss段的开始位置
.bss : { *(.bss) }; 指定bss段
_end = .; 把_end赋值为当前位置,即bss段的结束位置
} xloader是在系统上电之后，执行完ROM中的frimware后最先开始执行的用户程序，它的体积很小，执行的功能也很简单，主要是对系统时钟以及外部SDRAM进行初始化，初始化完成之后就检查Flash中的ubootimage是否准备好，如果准备好了就将Flash中的uboot image根据image header中指定的loadaddress加载到外部SDRAM中，然后就跳转到uboot执行代码。
这里，我试图从头开始，在源代码级别上来分析整个系统的引导过程。
像Xloader或者uboot之类的程序，并不像我们平常写的应用程序那样，程序的入口函数直接找main函数就行。对于这种系统程序，在最开始看代码，尤其是要找到最开始执行的代码的位置的时候，最好的一个方法就是找到整个工程的.lds文件，也就是链接脚本文件（linkerloaderscript）。它定义了整个工程在编译之后的链接过程，以及各个输入目标文件中的各个段在输出目标文件中的分布。详细的关于lds文件的介绍可以参考gnu的在线文档：http://sourceware.org/binutils/docs/ld/index.html。其中的第三节LinkerScript对链接脚本文件进行了介绍。
现在，我们首先开看一看xloader.lds的代码：
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm","elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(XLOADER_ENTRY)
SECTIONS
{
}
下面，我们对这一段代码逐句进行分析。
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm","elf32-littlearm")
在GNU的文档中，是这么定义的：
OUTPUT_FORMAT(default, big,little)，在链接的时候，如果使用了-EB的命令行参数，则使用这里的big参数指定的字节序，如果使用了-EL的命令行参数，则使用这里的little参数指定的字节序，如果没有使用任何命令行参数，则使用这里的default参数指定的字节序。
由xloader.lds中的定义可见，不管在链接的时候使用了何种命令行参数，输出的目标文件都是使用elf32-littlearm方式的字节序。
OUTPUT_ARCH(arm)
在GNU的文档中，是这么定义的：
OUTPUT_ARCH(bfdarch)，也就是指定了目标的体系结构，在这里，SpearPlus内部使用的处理器核是arm926ejs的，因此体系结构也就是arm。
ENTRY(XLOADER_ENTRY)
在GNU的文档中，是这么定义的：
ENTRY(symbol)
There are several ways to set the entry point. The linker will setthe entry point by trying each of the following methods in order,and stopping when one of them succeeds:
也就是说，ENTRY(XLOADER_ENTRY)定义了整个程序的入口处，也就是在标号XLOADER_ENTRY处。整个程序将从这里开始运行。
接下来的部分，是对整个输出目标文件中各个段的存储位置的定义。
在GNU的文档中，是这么定义的：
SECTIONS
对于其中的每一个sections-command，其完整的定义如下：
The full description of an output section looks likethis:
Most output sections do not use most of the optional sectionattributes.
The whitespace around section is required, so that the section nameis unambiguous. The colon and the curly braces are also required.The line breaks and other white space areoptional.
下面来看看xloader.lds中SECTIONS的定义：
SECTIONS
{