【裸机开发】链接脚本（.lds文件）实战：从基础语法到内存布局优化

1. 链接脚本：裸机开发的“内存规划师”

刚开始玩裸机开发那会儿，我总觉得链接脚本（.lds文件）是个特别神秘的东西。编译、链接这些流程，IDE通常都帮你默默处理好了，你只管写代码就行。直到有一次，我需要在SRAM里跑一段关键代码，在DDR里放数据，结果程序一跑就飞，怎么都找不到原因。折腾了好几天，最后才发现是链接脚本没配好，代码和数据放错地方了。那次经历让我彻底明白，在裸机开发里，链接脚本就是你程序的“内存规划师”，它决定了你的代码、变量最终躺在内存的哪个角落。

简单来说，链接脚本就是告诉链接器（比如GNU的ld）：“嘿，你把这些编译好的.o文件里的代码段（.text）、数据段（.data）、未初始化数据段（.bss）等等，按照我画的这张地图，摆到内存的指定位置去。” 没有操作系统帮你管理内存，这个布局就得你自己来操心。它直接关系到你的程序能不能正确加载、能不能高效运行，甚至能不能跑起来。

为什么在嵌入式裸机开发里，这个文件尤其重要？因为资源太紧张了。你的芯片可能内部有几十KB的SRAM，外面挂了几百MB的DDR，还有一块NOR Flash。上电后，代码要从Flash加载到RAM里执行，或者直接在Flash里原地执行（XIP）。不同的内存速度、容量、特性都不一样。链接脚本就是让你能精细地控制，哪段代码放SRAM（快），哪段数据放DDR（大），中断向量表必须放在哪个固定地址。可以说，不懂链接脚本，裸机开发就只学了一半。

2. 拆解.lds：从基础命令到核心结构

一个链接脚本，看起来一堆符号和括号，其实结构很清晰。咱们先从一个最简单的骨架说起，然后往里填肉。

2.1 核心框架：SECTIONS命令

链接脚本的灵魂就是 SECTIONS 命令，所有关于内存布局的“规划”都在这个大括号里完成。它的基本样子是这样的：

SECTIONS
{
    /* 这里就是我们的内存布局规划图 */
    . = 0x80000000; /* 首先，把“当前位置指针”指向内存起始地址 */
    .text : { *(.text) } /* 把所有输入文件的.text段收集起来，放在这里 */
    .data : { *(.data) } /* 接着放.data段 */
    .bss : { *(.bss) }  /* 最后放.bss段 */
}

这个脚本做了三件事：

1. . = 0x80000000;：这个点号 . 是个定位器计数器，你可以把它想象成一个在内存地址空间里移动的“光标”。这行代码把光标初始位置设在了 0x80000000，通常这就是我们DDR内存的起始地址。
2. .text : { *(.text) }：定义了一个名为 .text 的输出段。冒号后面的 { *(.text) } 是输入段描述，意思是“把所有输入目标文件（*.o）里的 .text 段，全部收集起来，合并放到我们输出的 .text 段里”。链接器会按照它遇到文件的顺序，把代码段一个一个拼接起来。
3. 同理，.data 和 .bss 段也是这么处理的。

这只是一个最基础的布局。实际项目中，我们往往需要更精细的控制，比如指定某个特定的.o文件必须放在最前面（比如包含启动代码的文件），或者把不同文件的同一种段分开存放。

2.2 关键命令与内置变量

除了 SECTIONS，还有几个命令出场率极高：

• ENTRY(symbol)：指定程序的入口点。比如 ENTRY(_start) 就告诉链接器，程序的第一条指令从符号 _start 所在的地址开始执行。这在裸机启动时至关重要，因为芯片上电复位后，会从一个固定地址（比如0x80000000）取指执行，这个地址存放的必须是 _start 的代码。
• MEMORY：这个命令太有用了，它能让你定义内存区域。比如你的芯片内存不是连续一块，有SRAM、有DDR，用这个命令可以清晰划分。

MEMORY
{
    SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
    DDR (rwx)  : ORIGIN = 0x80000000, LENGTH = 512M
}

这里定义了两块内存：SRAM 可读可写可执行，从0x20000000开始，大小128KB；DDR 也是可读可写可执行，从0x80000000开始，大小512MB。定义好后，在 SECTIONS 里就可以用 >SRAM 或 >DDR 来指定某个段放到哪块内存了。

至于内置变量，其实就是那些常见的段名：

• .text：代码段，存放你的函数指令。
• .data：已初始化的全局变量和静态变量（初始值非零）。
• .rodata：只读数据段，比如字符串常量、const修饰的全局变量。
• .bss：未初始化或初始化为零的全局变量和静态变量。这个段在elf文件里不占空间，但运行时需要在内存中预留位置并清零。
• .heap 和 .stack：堆和栈段，在更复杂的脚本里需要手动规划。

3. 实战：优化内存布局的三大技巧

懂了基础语法，咱们来点实战的。怎么让链接脚本真正为你的项目服务，提升性能和可靠性？我分享三个最常用的技巧。

3.1 地址对齐：让CPU跑得更快

内存控制器访问内存时，通常有对齐要求。比如32位ARM CPU，一次总线访问读取4字节（32位）效率最高。如果你的数据地址是0x80000001，CPU想读一个4字节整数，就得先读0x80000000-0x80000003，再读0x80000004-0x80000007，然后拼凑出你想要的数据，这太慢了。

链接脚本里用 ALIGN() 函数来解决这个问题。看这个例子：

SECTIONS
{
    . = 0x80000000;
    .text : {
        *(.text)
    }
    . = ALIGN(4); /* 确保当前位置是4字节对齐的 */
    .rodata : {
        *(.rodata)
    }
    .data ALIGN(8) : { /* 也可以直接跟在段名后面 */
        *(.data)
    }
    . = ALIGN(4);
    .bss : {
        *(.bss)
    }
}

假设 .text 段结束在地址 0x80001003。如果没有 . = ALIGN(4);，.rodata 段就会紧接着从 0x80001003 开始，这显然不是4字节对齐。加了 ALIGN(4) 后，链接器会把当前位置“垫高”到下一个4的整数倍地址，也就是 0x80001004，然后再开始放置 .rodata。.data 段后面的 ALIGN(8) 意思也一样，保证 .data 段的起始地址是8字节对齐的。

对齐不仅关乎速度，在某些架构下，不对齐的访问甚至会引发硬件异常（比如ARM的某些模式）。所以，在关键段（尤其是代码段和中断向量表）前后加上对齐操作，是个好习惯。

3.2 多内存区域管理：SRAM与DDR的协同作战

这是嵌入式裸机开发的核心场景。SRAM速度快，但容量小；DDR容量大，但速度相对慢，而且需要初始化后才能用。合理的分配策略是：把对性能最敏感、最关键的代码（比如启动代码、中断服务程序）放到SRAM；把大量的只读数据、代码和全局变量放到DDR。

结合前面提到的 MEMORY 命令，我们可以这样写：

MEMORY
{
    SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
    DDR (rwx)  : ORIGIN = 0x80000000, LENGTH = 512M
}

SECTIONS
{
    /* 第一阶段：在SRAM中执行的启动代码和中断向量表 */
    .isr_vector 0x20000000 : {
        KEEP(*(.isr_vector)) /* KEEP确保即使未被引用，该段也不会被优化掉 */
    } >SRAM

    .fast_code : {
        *(.fast_code) /* 你可以通过GCC属性将特定函数放到这个自定义段 */
        *startup.o(.text) /* 确保startup.o的代码在SRAM里 */
    } >SRAM

    /* 第二阶段：主程序放到DDR */
    .text : {
        *(.text)
        *(.text.*)
    } >DDR

    .rodata : {
        *(.rodata)
        *(.rodata.*)
    } >DDR

    .data : {
        _data_start = .;
        *(.data)
        *(.data.*)
        _data_end = .;
    } >DDR AT>SRAM /* 注意这里！VMA在DDR，但LMA在SRAM */

    .bss (NOLOAD) : { /* NOLOAD表示该段不加载到镜像文件，仅预留地址空间 */
        _bss_start = .;
        *(.bss)
        *(.bss.*)
        *(COMMON)
        _bss_end = .;
    } >DDR
}

这里有几个关键点：

1. >SRAM 和 >DDR：指定输出段存放在哪块内存区域（VMA，虚拟内存地址/程序运行地址）。
2. AT>SRAM：这是一个高级用法。它指定了加载地址（LMA）。对于 .data 段，它的运行时地址（VMA）在DDR（>DDR），但它的初始值在镜像文件里，需要被加载到SRAM（AT>SRAM）这个临时位置。为什么？因为DDR在系统刚启动时可能还没初始化！你的启动代码需要先把 .data 段的初始值从SRAM（或Flash）拷贝到DDR的最终位置。这通过 _data_start, _data_end 这些符号在C代码里实现。
3. 自定义段：像 .fast_code，你可以通过GCC的 __attribute__((section(".fast_code"))) 把某个函数标记为需要放到快速内存中。
4. 符号赋值：_bss_start = .; 这行代码创建了一个全局符号 _bss_start，它的值等于当前位置计数器 . 的值，也就是.bss段的起始地址。在C代码里声明 extern uint32_t _bss_start;，就可以在启动代码中用这个地址来清零.bss段了。

3.3 自定义符号与段：实现高级功能

链接脚本不只是被动地安排内存，还能主动创建符号和定义特殊段，实现一些“黑魔法”。

场景一：精确获取段边界。 前面已经看到了 _bss_start 和 _bss_end 的用法。对于.data段也一样，我们需要知道它的加载地址（LMA，在Flash/SRAM里）和运行地址（VMA，在DDR里），才能在启动时完成数据搬运。

.data : {
    _data_vma_start = .;    /* 在DDR中的起始地址 (VMA) */
    *(.data)
    _data_vma_end = .;
} >DDR AT>FLASH /* 假设从Flash加载 */

_data_lma_start = LOADADDR(.data); /* 获取.data段在Flash中的加载地址 (LMA) */

在C启动文件中，你就可以这样写：

extern uint32_t _data_vma_start, _data_vma_end, _data_lma_start;
void copy_data_section(void) {
    uint32_t *src = &_data_lma_start;
    uint32_t *dst = &_data_vma_start;
    while (dst < &_data_vma_end) {
        *dst++ = *src++;
    }
}

场景二：构建初始化函数表。 这是一个在RTOS（如RT-Thread）中广泛使用的技巧，用于实现组件的自动初始化，而不需要硬编码调用顺序。

首先，在C头文件中定义一个宏：

#define INIT_EXPORT(fn, level) \
    __attribute__((used, section(".init_fn." level))) const init_fn_t _init_##fn = fn

然后，在不同的模块初始化函数上使用不同的宏：

INIT_EXPORT(board_init, "1"); // 板级初始化，优先级1
INIT_EXPORT(device_init, "3"); // 设备初始化，优先级3

最后，在链接脚本里，把这些分散在各处的函数指针收集到一个连续的数组中：

.init_array : {
    __init_array_start = .;
    KEEP(*(SORT(.init_fn.*))) /* SORT会按段名后的数字排序！ */
    __init_array_end = .;
} >SRAM

系统启动时，只需要从 __init_array_start 遍历到 __init_array_end，依次调用这些函数指针即可。新增模块完全不需要修改主初始化流程，链接器帮你完成了“注册”。

4. 避坑指南：那些年我踩过的链接脚本的“坑”

语法看起来简单，但实际写起来，坑可不少。我总结了几类最常见的问题。

第一坑：地址重叠。 这是最致命也最隐蔽的错误。比如你算错了某个段的大小，或者没考虑对齐填充，导致.text段和.data段地址重叠了。程序可能能加载，但一运行就数据错乱。务必在链接后查看生成的map文件（GCC加 -Wl,-Map=output.map 选项）。map文件里详细列出了每个段、每个符号的最终地址和大小，是排查内存布局问题的终极武器。

第二坑：忘记清零.bss段。 链接脚本只负责告诉程序.bss段在哪里、有多大，但不会自动帮你清零。如果启动代码里漏了这一步，那么未初始化的全局变量就会是随机值，程序行为不可预测。记住，清零.bss是C运行时环境初始化必不可少的一步。

第三坑：启动文件顺序错误。 包含中断向量表和最开始几条跳转指令的启动文件（通常是 startup.o 或 vectors.o），必须放在输出.text段的最前面。因为芯片上电后，是从内存起始地址取指令执行的。如果你的链接脚本是 *(.text)，那么链接器按什么顺序链接.o文件是不确定的。正确做法是显式指定：

.text : {
    startup.o (.text) /* 确保第一 */
    *(.text)
}

第四坑：对齐导致的空洞浪费。 为了对齐，链接器可能会在段与段之间插入填充字节。在内存紧张的单片机环境，这可能浪费几百字节甚至几K的空间。你需要权衡性能和空间。有时可以调整段的顺序，让大小相近的段放在一起，减少对齐造成的总空洞。也可以使用 SUBALIGN 来指定子对齐，但需谨慎。

第五坑：跨域访问未考虑。 比如你把代码放在0x00000000开始的Flash区域（XIP执行），但把.data段放在了0x20000000的SRAM。如果你的代码里有一条直接寻址访问.data的指令，而CPU的地址总线或内存控制器不支持从0x00000000地址直接访问0x20000000的区域（可能需要特殊的重映射或配置），那么这条指令就会失败。在设计内存布局时，必须结合芯片的内存映射图来考虑。

5. 进阶：链接脚本的调试与验证

写好了链接脚本，怎么知道它工作得对不对呢？光编译通过可不行。

首要工具：Map文件。 前面提过，用 -Wl,-Map=project.map 生成map文件。打开它，重点看这几部分：

1. Memory Configuration：确认你定义的 MEMORY 区域是否正确。
2. Linker script and memory map：这是核心。找到你的输出段（比如 .text, .data），看它们的起始地址（VMA）和结束地址是否符合预期，是否在正确的内存区域。检查关键符号（如 _bss_start, _etext）的地址。
3. 检查是否有任何段超出了你定义的 MEMORY 区域长度。

辅助工具：objdump和readelf。 生成elf文件后，可以用 arm-none-eabi-objdump -h project.elf 查看各段头部信息，包括大小、VMA、LMA。用 arm-none-eabi-readelf -s project.elf 可以查看符号表，确认你定义的链接脚本符号（如段边界符号）是否存在且地址正确。

终极测试：写个测试用例。 在程序最开始，打印出关键符号的地址：

extern char _text_start, _text_end, _data_start, _data_end, _bss_start, _bss_end;
printf("Text: %p - %p\n", &_text_start, &_text_end);
printf("Data: %p - %p\n", &_data_start, &_data_end);
printf("BSS:  %p - %p\n", &_bss_start, &_bss_end);

看看输出是否和你链接脚本里设计的一致。同时，可以在这几个段的前后设置“警戒值”（比如0xDEADBEEF），运行一段时间后检查这些值是否被意外修改，以检测栈溢出或数组越界等问题。

6. 不同架构下的细微差异

虽然GNU ld的链接脚本语法是通用的，但不同架构的芯片，其内存映射、启动方式可能不同，链接脚本也需要相应调整。

以ARM Cortex-M系列为例：它的中断向量表必须放在Flash起始地址（通常是0x08000000）。向量表的第一项是初始栈指针（MSP）的值，第二项是复位向量（Reset_Handler）。所以链接脚本里，必须确保包含向量表的那个.o文件（比如 startup_stm32fxxx.o）的 .isr_vector 段放在最前面。

MEMORY
{
    FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
    SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
    .isr_vector : {
        KEEP(*(.isr_vector))
    } >FLASH

    .text : {
        *(.text)
    } >FLASH
    /* ... 其他段 */
}

而对于像i.MX RT这样的跨界处理器，它可能没有内部Flash，程序放在外部QSPI Flash中，但希望全速在内部的ITCM（指令紧耦合内存）运行。这就涉及到XIP（就地执行）和代码重定位。链接脚本会更复杂，需要定义两个.text段：一个在Flash（LMA），一个在ITCM（VMA），并在启动代码中将代码从Flash拷贝到ITCM。

RISC-V架构可能又有所不同，但核心思想不变：根据芯片手册的内存映射，在 MEMORY 中定义好区域，在 SECTIONS 中根据启动流程和性能需求，合理安排各个段的VMA和LMA。

说到底，链接脚本没有一成不变的模板。最好的学习方式就是找一块开发板，从最简单的“Hello World”裸机程序开始，尝试修改链接脚本，把代码段、数据段放到不同的地址，然后观察程序行为，同时结合map文件和反汇编（objdump -d）来理解每一步修改带来的变化。这个过程可能会遇到各种奇怪的问题，但每解决一个，你对程序如何从源代码变成在内存中运行的二进制映像的理解就会加深一层。当你能够根据芯片手册和项目需求，熟练地定制出最合适的内存布局时，你会发现，链接脚本这个“内存规划师”，已经成了你嵌入式开发工具箱里一件非常得心应手的利器。