1. 为什么需要自定义链接脚本

刚开始玩STM32F103C8Tx的时候，我也觉得链接脚本这东西挺神秘的，直到有一次我的程序莫名其妙地崩溃，才发现是内存不够用了。这款芯片只有64KB的FLASH和20KB的RAM，资源真的非常紧张。如果你只是写点简单的代码，用默认的链接脚本可能没问题，但一旦项目复杂起来，比如用了RTOS、文件系统或者网络协议栈，内存就变得捉襟见肘了。

链接脚本就像是给芯片内存世界画地图的工具，它决定了代码、数据、堆栈各自住在哪个地址房间。默认的脚本虽然能用，但往往不够精细，可能会浪费宝贵的内存空间。我自己就遇到过因为堆栈空间不足导致系统随机崩溃的情况，后来通过自定义链接脚本，硬是从有限的20KB RAM中挤出了更多可用空间。

实际项目中，这些情况你可能需要自定义链接脚本：当你的程序经常因为堆栈溢出而崩溃；当编译时提示RAM或FLASH不足；当你需要将特定数据放在固定地址（比如EEPROM模拟）；或者当你想要优化启动速度，减少数据复制时间。这些都是我亲身踩过的坑，后面我会详细分享怎么解决。

2. 理解STM32F103C8Tx的内存布局

STM32F103C8Tx的内存结构其实很简单，但理解清楚是优化的基础。我们先来看看它的内存地图：FLASH从0x8000000开始，总共64KB，也就是0x10000字节。这里主要存放程序代码、常量数据和中断向量表。RAM从0x20000000开始，总共20KB（0x5000字节），这里存放变量、堆栈和运行时数据。

中断向量表必须放在FLASH的最开始位置（0x8000000），这是STM32硬件决定的，否则芯片上电后找不到正确的入口地址。代码段（.text）紧接着向量表存放，然后是只读数据（.rodata），这些都在FLASH中。

RAM的布局就比较灵活了。初始化的数据（.data）需要从FLASH复制到RAM，未初始化的数据（.bss）则在启动时被清零。堆栈通常放在RAM的末尾，因为栈是向下生长的，这样安排可以避免堆栈冲突。

我刚开始时没太注意这些细节，结果有一次定义了一个大数组，导致堆栈被覆盖，系统运行几天后随机死机。后来用链接脚本精细控制内存分配，问题才彻底解决。这就是为什么要了解内存布局的原因——避免那些难以调试的内存问题。

3. 链接脚本基础与语法详解

链接脚本的语法其实不难，主要是理解几个关键概念。ENTRY(Reset_Handler)指定程序的入口点，也就是芯片上电后执行的第一条指令。_estack = ORIGIN(RAM) + LENGTH(RAM)则定义栈顶地址，也就是RAM的末尾位置。

MEMORY部分定义了内存区域，对STM32F103C8Tx来说就是这样：

MEMORY {
  RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K
  FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 64K
}

(xrw)表示可执行、可读、可写，(rx)表示可执行、可读。这些属性很重要，链接器会根据属性决定把哪些段放到哪里。

SECTIONS部分是核心，它定义了各个段如何放置。比如.isr_vector必须放在FLASH开头：

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

KEEP确保向量表不会被链接器优化掉，即使没有显式引用也要保留。

.text段存放代码，.rodata存放只读数据。特别注意.ARM.exidx段，这是异常处理相关的，必须放在FLASH中且保持正确顺序，否则调试时会遇到问题。

.data段比较特殊，它用AT>指定加载地址（LMA）在FLASH，但运行地址（VMA）在RAM。这样上电后启动代码才能知道从哪里复制数据到RAM。

.bss段包含未初始化数据，启动代码会将其清零。最后是堆栈段，通常放在RAM末尾。

我第一次写链接脚本时，忘了加ALIGN(4)对齐，结果程序运行异常。STM32是32位架构，内存访问最好4字节对齐，否则会影响性能和稳定性。这些都是实战中积累的经验。

4. 实战优化：堆栈空间动态调整

堆栈空间优化是我觉得最实用的技巧。默认链接脚本往往给堆栈固定分配空间，比如512字节堆和1KB栈。但在实际项目中，这通常不够用。

通过链接脚本，我们可以动态调整堆栈大小。首先在脚本开头定义：

_Min_Heap_Size = 0x200;   /* 512字节 */
_Min_Stack_Size = 0x400;  /* 1KB */

然后在SECTIONS里这样分配：

._user_heap_stack : {
  . = ALIGN(8);
  PROVIDE (end = .);
  PROVIDE (_end = .);
  . = . + _Min_Heap_Size;
  . = . + _Min_Stack_Size;
  . = ALIGN(8);
} >RAM

但更聪明的方法是先分配其他段，剩余的空间都给堆栈。我们可以计算已用RAM大小，然后动态调整堆栈：

._user_heap_stack : {
  . = ALIGN(8);
  PROVIDE (end = .);
  PROVIDE (_end = .);
  . = ORIGIN(RAM) + LENGTH(RAM) - _Min_Stack_Size;
  . = ALIGN(8);
} >RAM

这样堆栈就会紧挨着RAM末尾，最大化利用空间。我曾经用这种方法在一个项目中多争取了2KB的RAM空间，足够存放额外的通信缓冲区。

还有一个技巧是使用PROVIDE定义符号，让程序运行时可以知道堆栈信息：

PROVIDE(__heap_start = .);
PROVIDE(__heap_end = ORIGIN(RAM) + LENGTH(RAM) - _Min_Stack_Size);
PROVIDE(__stack_top = ORIGIN(RAM) + LENGTH(RAM));

这样在代码中就可以监控堆栈使用情况，实现动态调整。我习惯在系统空闲时检查堆栈水位，如果接近极限就输出警告，便于提前发现问题。

5. 关键段的精细分配策略

.data和.bss段的分配对内存利用率影响很大。默认配置往往简单地把所有.data和.bss连续放置，但我们可以做得更精细。

首先，频繁访问的数据应该放在RAM开头，因为STM32的内存控制器对低地址访问有优化。我们可以把需要快速响应的数据单独放在一个段：

在C代码中：

__attribute__((section(".fast_data"))) uint32_t buffer[128];

在链接脚本中：

.fast_data : {
  *(.fast_data)
} >RAM AT>FLASH

启动代码需要相应修改，在复制.data段时也要复制.fast_data段。

对于.bss段，同样可以把需要快速初始化的变量单独分组：

.fast_bss (NOLOAD) : {
  *(.fast_bss)
} >RAM

NOLOAD告诉链接器这个段不需要初始化，节省启动时间。

常量数据优化也很重要。默认情况下，const变量放在.rodata段，但有些常量其实可以放在.text段，特别是那些与代码紧密相关的常量：

.text : {
  *(.text)
  *(.text.*)
  *(.rodata)  /* 把rodata放在text段内，提高访问效率 */
  *(.rodata*)
} >FLASH

这样布局更紧凑，提高缓存利用率。我曾经通过这种优化，让一个数字信号处理算法的速度提升了15%。

另一个技巧是使用ARM的编译特性，把小的全局变量放在特定的段：

__attribute__((section(".tiny_bss"))) uint8_t flag;

然后在链接脚本中优先分配这些段，确保它们使用低地址，减少指令编码长度。

6. 避免内存碎片的高级技巧

内存碎片是嵌入式系统的大敌，特别是长期运行的系统。通过链接脚本可以一定程度上避免碎片。

首先是对齐策略。过度对齐会浪费空间，但对齐不足会影响性能。我的经验是：代码4字节对齐，数据按数据类型大小对齐（8位数据1字节对齐，32位数据4字节对齐），堆栈8字节对齐。

.text : {
  . = ALIGN(4);  /* 代码4字节对齐 */
  *(.text)
} >FLASH

.data : {
  . = ALIGN(4);  /* 数据4字节对齐 */
  *(.data)
} >RAM AT>FLASH

其次是段合并。链接器默认会合并相同属性的段，但有时需要手动控制：

.bss : {
  *(.bss)
  *(.bss.*)
  *(COMMON)
  . = ALIGN(4);
} >RAM

*(COMMON)表示未初始化的全局变量，确保它们被正确合并到.bss段。

对于多模块项目，可以控制模块的段顺序：

.text : {
  *driver*.o(.text)   /* 先放驱动代码 */
  *(.text)            /* 其他代码 */
} >FLASH

这样重要的代码放在前面，提高缓存命中率。

我还喜欢用填充来确保段大小是2的幂次：

.data : {
  *(.data)
  . = ALIGN(4);
  FILL(0xFF);
  . = ALIGN(16);  /* 填充到16字节边界 */
} >RAM AT>FLASH

这看起来浪费空间，但实际上有利于内存管理器的效率。

最后是使用链接器提供的符号来监控内存使用：

.data : {
  _data_start = .;
  *(.data)
  _data_end = .;
} >RAM AT>FLASH

.bss : {
  _bss_start = .;
  *(.bss)
  _bss_end = .;
} >RAM

在代码中可以通过这些符号计算实际使用量，动态调整内存分配策略。

7. 调试技巧与常见问题解决

链接脚本调试确实有点棘手，但掌握一些技巧后就能事半功倍。首先一定要生成map文件，在编译选项中加入-Wl,-Map=output.map。这个文件会详细记录每个段的位置、大小和符号地址。

我习惯在map文件中搜索这些关键信息：内存区域的使用情况、各个段的大小、重要符号的地址。有一次发现中断响应变慢，最后在map文件中发现关键代码段被放在FLASH末尾，访问速度较慢。

链接器错误信息也要学会解读。"section .text will not fit in region FLASH"说明代码太大；"region RAM overflowed"说明RAM不足；"undefined reference"可能是链接脚本中缺少必要的段。

调试时还可以使用PROVIDE定义调试符号：

PROVIDE(__flash_start = ORIGIN(FLASH));
PROVIDE(__flash_end = ORIGIN(FLASH) + LENGTH(FLASH));

在代码中可以输出这些信息帮助调试。

常见问题中，最多的是堆栈溢出。我通常会在堆栈区域填充特定模式：

._user_heap_stack : {
  /* 填充堆栈区域为0xDEADBEEF */
  FILL(0xDEADBEEF);
  . = ALIGN(8);
  PROVIDE (end = .);
  . = . + _Min_Heap_Size;
  . = . + _Min_Stack_Size;
  . = ALIGN(8);
} >RAM

当堆栈溢出时，内存中会出现这个模式，容易发现。

另一个常见问题是数据未正确初始化。确保启动代码正确复制.data段和清零.bss段。可以在启动代码中加入校验：

/* 检查.data段复制 */
if (memcmp(_sdata, _sidata, _edata - _sdata) != 0) {
  /* 处理错误 */
}

/* 检查.bss段清零 */ 
for (uint8_t *p = _sbss; p < _ebss; p++) {
  if (*p != 0) {
    /* 处理错误 */
  }
}

最后建议版本控制中保存链接脚本，每次修改都记录原因。我曾经因为忘记某个修改导致奇怪问题，回退版本才解决。