1. 链接脚本：嵌入式系统的"交通指挥官"

第一次接触链接脚本时，我完全被那些奇怪的符号和命令搞懵了。直到有一次项目出现奇怪的运行时崩溃，花了三天时间才发现是因为关键中断向量表被链接器优化掉了——那一刻我才真正明白链接脚本的重要性。简单来说，链接脚本就像嵌入式系统的"交通指挥官"，它告诉链接器：

• 哪些代码必须保留（KEEP）
• 内存如何划分（MEMORY）
• 变量应该放在哪里（AT）
• 如何对齐数据（ALIGN）
• 怎样向应用层暴露接口（PROVIDE）

举个例子，在RISC-V架构中，__global_pointer$这个符号对性能优化至关重要。如果没有正确设置，你的程序可能会慢上20%。这就是为什么我们需要深入理解这些命令：

PROVIDE( __global_pointer$ = . + 0x800 );

2. KEEP命令：关键代码的"免死金牌"

2.1 为什么需要KEEP

编译器优化是个"双刃剑"。有一次我调试FreeRTOS时，发现任务切换总是莫名其妙失败，最后发现是调度器用到的几个关键函数被链接器当作"未引用代码"删除了。这就是KEEP的用武之地——它相当于给关键代码段发"免死金牌"。

常见需要KEEP的场景：

• 中断向量表（没有显式调用的关键代码）
• 构造函数/析构函数（编译器自动生成的初始化代码）
• 厂商提供的预编译库中的关键符号

2.2 实战中的KEEP用法

在RISC-V项目中，典型的初始化代码保护是这样写的：

.init : {
    _text = .;
    KEEP(*(SORT_NONE(.init)))  /* 保证.init段不被丢弃 */
} >rom AT>rom

特别注意SORT_NONE这个参数——它告诉链接器不要对这部分内容进行任何排序优化。我曾经遇到过因为缺少这个修饰符导致初始化顺序错误的问题。

3. MEMORY命令：内存规划的"城市规划图"

3.1 内存区域定义的艺术

嵌入式设备的内存往往分多个区域：Flash、SRAM、外部RAM等。MEMORY命令就是定义这些区域的"城市规划图"。一个常见的误区是只定义大小而忽略属性：

MEMORY {
    /* 错误示例：缺少属性修饰 */
    rom : ORIGIN = 0x80000000, LENGTH = 512K  
    
    /* 正确示例：带访问权限 */
    rom (rxa) : ORIGIN = 0x80000000, LENGTH = 512K
    ram (wxa) : ORIGIN = 0x80080000, LENGTH = 512K
}

括号里的属性字母很关键：

• r：可读
• w：可写
• x：可执行
• a：可分配

3.2 实际项目中的内存布局

在包含FreeRTOS的项目中，我通常会这样划分内存：

MEMORY {
    /* Bootloader区域 */
    bl (rx)  : ORIGIN = 0x80000000, LENGTH = 64K
    
    /* 主程序Flash */
    app (rx) : ORIGIN = 0x80010000, LENGTH = 448K
    
    /* 数据RAM */
    ram (wxa): ORIGIN = 0x20000000, LENGTH = 128K
    
    /* 特殊用途RAM（如DMA缓冲区） */
    special (wxa) : ORIGIN = 0x20020000, LENGTH = 64K
}

这种布局既考虑了引导需求，又为特殊硬件功能保留了专用内存区域。

4. PROVIDE命令：模块间的"通信管道"

4.1 符号导出的三种姿势

PROVIDE的妙处在于它允许链接脚本向C代码暴露符号。这相当于在底层硬件和上层应用之间建立"通信管道"。但要注意三种不同用法：

1. 强定义（可能引发冲突）：

   __stack_size = 0x1000;
   

2. 弱定义（允许覆盖）：

   PROVIDE(__stack_size = 0x1000);
   

3. 条件定义（仅当未定义时）：

   PROVIDE(__stack_size = DEFINED(__stack_size) ? __stack_size : 0x1000);
   

4.2 RISC-V的特殊符号

在RISC-V开发中，这个符号尤为重要：

PROVIDE( __global_pointer$ = . + 0x800 );

它定义了全局指针的基准地址，用于优化内存访问。如果设置不当，会导致：

• 性能下降（多出20%的内存访问指令）
• 代码体积膨胀（多出15%左右）
• 某些优化无法生效

5. ENTRY与AT：启动与重定位的关键

5.1 程序入口的陷阱

ENTRY看似简单，但隐藏着大坑。有一次我的系统就是无法启动，最后发现是因为：

/* 错误：_start可能被优化掉 */
ENTRY(_start)

/* 正确：确保入口保留 */
ENTRY(_start)
.text : {
    KEEP(*(.text._start))  /* 显式保留入口代码 */
}

5.2 AT命令与数据重定位

AT命令实现了数据从加载地址到运行地址的重定位。这是嵌入式系统启动过程中最精妙的部分之一：

.data : {
    *(.data)
    _edata = .;
} >ram AT>rom  /* 运行时在RAM，但存储在ROM */

对应的启动代码需要完成数据搬运：

/* 在_start函数中 */
extern char _sdata, _edata, _sidata;
memcpy(&_sdata, &_sidata, &_edata - &_sdata);

我曾经遇到过因为忘记这个拷贝操作，导致所有全局变量初始值全为零的诡异bug。

6. ALIGN与LOADADDR：细节决定成败

6.1 对齐的艺术

不对齐访问在有些架构上会导致硬件异常。ALIGN命令就是解决这个问题的：

.bss : {
    . = ALIGN(4);  /* 确保4字节对齐 */
    *(.bss)
    . = ALIGN(8);  /* 后续内容8字节对齐 */
    _ebss = .;
}

实际项目中，不同硬件有不同的对齐要求：

• 32位MCU通常需要4字节对齐
• DMA缓冲区可能需要32字节甚至64字节对齐
• 加密引擎可能有特殊的对齐要求

6.2 加载地址查询

LOADADDR在启动代码中非常有用：

.data : {
    _data_lma = LOADADDR(.data);  /* 获取加载地址 */
    *(.data)
} >ram AT>rom

对应的启动代码可以这样使用：

uint32_t *src = (uint32_t*)&_data_lma;
uint32_t *dst = (uint32_t*)&_sdata;
while(dst < (uint32_t*)&_edata) *dst++ = *src++;

7. FreeRTOS链接脚本实战分析

7.1 任务栈的特殊处理

在FreeRTOS中，任务栈需要特殊对待：

.stack : {
    . = ALIGN(16);
    . += __stack_size;
    _stack_top = .;  /* 栈顶指针 */
} >ram

这里有几个关键点：

• ALIGN(16)确保栈按照ABI要求对齐
• += 直接在当前位置分配空间
• _stack_top用于初始化任务的SP寄存器

7.2 静态分配与动态分配的结合

成熟的FreeRTOS项目通常会混合使用静态和动态内存：

/* 静态分配的堆 */
.heap : {
    . = ALIGN(8);
    _sheap = .;
    . += __heap_size;
    _eheap = .;
} >ram

/* 在C代码中使用 */
uint8_t ucHeap[ configTOTAL_HEAP_SIZE ] __attribute__((section(".heap")));

这种设计既保证了关键组件的可靠性，又保留了动态分配的灵活性。