2、链接脚本(.ld)与内存布局定制：通过修改链接脚本实现代码、数据、堆栈的精确定位与内存碎片消除
说实话，很多工程师做了好几年MCU开发，对链接脚本的态度就是「能用就行」。项目模板里那个.ld文件，几乎没人去动它。我以前也是这样，直到有一次产品量产时发现RAM不够用，才被迫去啃这块硬骨头。
链接脚本，说白了就是告诉编译器：你的代码该放哪，数据该放哪，堆栈该放哪。它决定了最终固件在Flash和RAM里的分布。如果你不主动管它，编译器就按默认规则来——这往往不是最优解。
2.1 链接脚本的核心结构
一个典型的.ld文件，我习惯把它拆成三块来看：内存区域定义、段定义、符号导出。咱们拿STM32F407的链接脚本举个例子：
/* 内存区域定义 */
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K
}
/* 段定义 */
SECTIONS
{
.text :
{
*(.isr_vector) /* 中断向量表 */
*(.text) /* 程序代码 */
*(.rodata) /* 只读数据 */
_etext = .; /* 代码结束地址 */
} > FLASH
.data : AT (ADDR(.text) + SIZEOF(.text))
{
_sdata = .;
*(.data) /* 初始化数据 */
_edata = .;
} > RAM
.bss :
{
_sbss = .;
*(.bss) /* 未初始化数据 */
*(COMMON)
_ebss = .;
} > RAM
}这里有个关键点：.data段用了AT指令。它的加载地址在Flash，运行地址在RAM。启动代码会负责把数据从Flash拷贝到RAM。嗯，这个拷贝过程很多人会忽略它的时间开销。
2.2 内存布局的定制策略
为什么要定制？因为默认布局有三大痛点：
- 碎片化：不同模块的数据混在一起，改一个模块可能影响全局
- 性能瓶颈：频繁访问的变量放在慢速内存上
- 安全风险：堆栈溢出可能悄无声息地覆盖关键数据
我在一个电机控制项目里遇到过这种情况：PID算法的系数放在默认RAM区，每次中断里都要读。后来我把它们挪到紧耦合内存（TCM）里，执行时间直接降了30%。
2.2.1 代码的精确定位
有时候你需要把特定函数放到固定地址。比如Bootloader的入口必须放在0x08000000，而应用程序要偏移到0x08020000。怎么做？
/* 在链接脚本中定义 */
SECTIONS
{
.bootloader 0x08000000 :
{
*(.bootloader_code)
}
.app_code 0x08020000 :
{
*(.text)
}
}
/* 在C代码中指定 */
__attribute__((section(".bootloader_code")))
void boot_entry(void)
{
/* 跳转到应用程序 */
}我个人习惯把中断密集型的函数（如定时器回调、通信中断处理）单独放在一个段里，然后映射到最快的内存区域。这样既保证了实时性，又不会影响其他代码。
2.2.2 数据的精细管理
数据段的管理比代码更讲究。我一般会分三类：
| 数据类型 | 推荐位置 | 原因 |
|---|---|---|
| 频繁读写变量 | DTCM / 紧耦合内存 | 单周期访问，无总线延迟 |
| 大块缓冲数据 | 外部SDRAM / SRAM | 容量大，适合FIFO、帧缓冲 |
| 只读配置参数 | Flash（.rodata） | 不占RAM，掉电不丢失 |
| 中断共享变量 | 非缓存区域 | 避免缓存一致性问题 |
举个例子，如果你有一个1KB的日志缓冲区，放在DTCM里就太浪费了。我会这样处理：
/* 链接脚本 */
.buffer (NOLOAD) : ALIGN(32)
{
*(.large_buffer)
} > SDRAM
/* C代码 */
__attribute__((section(".large_buffer")))
uint8_t log_buffer[1024];注意那个ALIGN(32)，这是对齐到32字节边界。很多DMA外设要求缓冲区地址对齐，提前在链接脚本里处理好，比在代码里做对齐要干净得多。
2.2.3 堆栈的隔离与保护
堆栈溢出是嵌入式开发里最难排查的问题之一。我曾经花了两天时间，才发现是任务栈溢出了，把全局变量表给覆盖了。
解决方案？给堆栈单独划一块区域，并且在前后放上「哨兵」：
/* 链接脚本 */
.stack (NOLOAD) : ALIGN(8)
{
_stack_start = .;
. = . + 0x400; /* 1KB主栈 */
. = ALIGN(8);
_stack_end = .;
_stack_guard = .; /* 哨兵区域 */
. = . + 0x40; /* 64字节保护带 */
} > RAM
/* 启动代码中检查 */
extern uint32_t _stack_guard;
void check_stack_overflow(void)
{
/* 如果哨兵区域被改写，说明栈溢出了 */
if (*(uint32_t *)_stack_guard != 0xDEADBEEF)
{
Error_Handler();
}
}对于ThreadX的多任务环境，每个任务栈也可以这样处理。我习惯在链接脚本里预留一块大的.task_stacks区域，然后在初始化时手动分配。这样所有任务栈都在一个连续区域里，方便调试器查看。
2.3 消除内存碎片
内存碎片分两种：堆碎片和段间碎片。堆碎片靠好的内存管理算法（比如ThreadX的字节池），段间碎片就得靠链接脚本了。
段间碎片是怎么产生的？看这个例子：
.text : 起始0x08000000，大小0x10000
.rodata : 起始0x08010000，大小0x2000
/* 这里空出了0xE000字节！ */
.data : 起始0x08020000因为.rodata只用了8KB，但下一个段必须从128KB边界开始，中间就浪费了56KB。解决办法是让链接器自动紧凑排列：
SECTIONS
{
.text : { *(.text) } > FLASH
.rodata : { *(.rodata) } > FLASH
/* 不需要指定起始地址，链接器会自动接在后面 */
}但有时候你又需要对齐。比如外部Flash的擦除块大小是64KB，那你放数据时最好按64KB对齐，否则更新一个块会影响其他数据。这里有个权衡：
- 追求空间利用率：不指定对齐，让链接器自动紧凑排列
- 追求更新效率：按擦除块大小对齐，牺牲一点空间
2.4 实战：ThreadX任务栈的精确映射
最后分享一个我在ThreadX项目里的实际做法。我需要8个任务，每个任务栈2KB，总共16KB。我不想让它们散落在RAM各处，而是集中放在一块连续区域：
/* 链接脚本 */
.task_stacks (NOLOAD) : ALIGN(32)
{
_task_stacks_start = .;
. = . + 0x4000; /* 16KB任务栈区域 */
_task_stacks_end = .;
} > RAM
/* 初始化代码 */
#define STACK_SIZE 2048
#define TASK_COUNT 8
extern uint32_t _task_stacks_start;
void create_all_tasks(void)
{
uint8_t *stack_base = (uint8_t *)&_task_stacks_start;
for (int i = 0; i < TASK_COUNT; i++)
{
tx_thread_create(
&task_blk[i],
"task",
task_entry,
(ULONG)i,
stack_base + i * STACK_SIZE,
STACK_SIZE,
/* 优先级等参数 */
);
}
}这样做的好处是：调试时打开内存视图，一眼就能看到所有任务栈的使用情况。哪个栈快溢出了，看剩余空间就知道。
2.5 本章知识结构
下面这张图总结了链接脚本定制与内存布局的核心逻辑：
链接脚本这东西，平时用不着，但一旦遇到内存瓶颈或者诡异的崩溃问题，它就是你的救命稻草。花半天时间把布局理清楚，比花三天去猜问题在哪要划算得多。