📚 课程目录第4章静态内存分配策略

4、静态内存分配策略：链接脚本(.ld)与内存映射文件(.map)的深度解析

说到嵌入式系统的内存管理，很多人第一反应是 malloc/free。但在我做过的项目中，尤其是那些对实时性要求苛刻的系统，动态分配往往是第一个被砍掉的功能。为什么？因为不可预测。你永远不知道一次 malloc 要花多久，也不知道堆碎片什么时候会把系统搞崩。

静态内存分配就不一样了。编译时就把一切安排好，运行时只管用。而要做到这一点，核心就是两个文件：链接脚本（.ld）和内存映射文件（.map）。说白了，一个告诉链接器怎么安排你的代码和数据，一个告诉你最终安排的结果。

4.1 链接脚本：嵌入式系统的“土地规划图”

链接脚本（Linker Script）是链接器的配置文件。它描述了目标芯片的内存布局，以及各个段（Section）应该放在哪里。我习惯把它比作一张土地规划图——哪里建住宅（.text），哪里建商业区（.data），哪里留作绿地（.bss），全得画清楚。

一个典型的链接脚本长这样：

/* 简单链接脚本示例 */
MEMORY
{
    FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
    RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
    .text :
    {
        *(.isr_vector)    /* 中断向量表 */
        *(.text*)          /* 程序代码 */
        *(.rodata*)        /* 只读数据 */
        _etext = .;        /* 代码结束地址 */
    } > FLASH

    .data : AT(ADDR(.text) + SIZEOF(.text))
    {
        _sdata = .;        /* 数据段起始地址 */
        *(.data*)          /* 初始化数据 */
        _edata = .;        /* 数据段结束地址 */
    } > RAM

    .bss :
    {
        _sbss = .;         /* BSS段起始地址 */
        *(.bss*)           /* 未初始化数据 */
        _ebss = .;         /* BSS段结束地址 */
    } > RAM
}

这里有几个关键点，我当年踩过坑：

MEMORY 命令：定义物理内存区域。地址和大小必须和芯片手册一致，写错了程序根本跑不起来。
SECTIONS 命令：定义如何将输入段（来自 .o 文件）映射到输出段，以及输出段放在哪个内存区域。
AT 关键字：指定加载地址（LMA）和运行地址（VMA）。.data 段在 Flash 里存着，但运行时得搬到 RAM 里。这个“搬”的动作，就是启动代码干的活。

核心概念：LMA vs VMA

LMA（Load Memory Address）：程序烧录时存放的地址，通常在 Flash 里。

VMA（Virtual Memory Address）：程序运行时实际使用的地址，通常在 RAM 里。

对于 .text 段，LMA 和 VMA 相同；对于 .data 段，两者不同，启动代码负责从 LMA 拷贝到 VMA。

4.2 内存映射文件：链接结果的“施工图纸”

.map 文件是链接器生成的输出文件，记录了每个符号、每个段的最终地址和大小。我每次编译完大型项目，第一件事就是打开 .map 文件看看——它能告诉我内存到底用成什么样了。

一个 .map 文件的核心内容通常包括：

信息类别	内容说明	我关注的点
Section Cross References	各段之间的引用关系	有没有不该引用的段被拉进来了
Memory Configuration	内存区域的起始地址和大小	和芯片手册对不对得上
Linker Script and Memory Map	每个段的起始地址、结束地址、大小	有没有段溢出到别的区域
Symbol Table	每个全局符号的地址和大小	哪个函数或变量占的空间最大

我曾经在一个项目中，发现 .bss 段莫名其妙多了 2KB。打开 .map 文件一查，原来是一个调试用的全局数组忘记删了。这种问题，光看代码很难发现，但 .map 文件一眼就能揪出来。

4.3 实战技巧：如何通过链接脚本优化内存布局

光会写链接脚本还不够，得知道怎么用它来优化。我总结了几个实战中常用的技巧：

4.3.1 自定义段：把关键数据放到指定位置

有些场景下，你需要把特定变量放到特定地址。比如，DMA 缓冲区需要对齐到 1KB 边界，或者某些共享内存需要放在固定位置。

/* 在 C 代码中声明自定义段 */
__attribute__((section(".dma_buf")))
uint8_t dma_buffer[1024] __attribute__((aligned(1024)));

/* 在链接脚本中定义该段 */
SECTIONS
{
    .dma_buf : ALIGN(1024)
    {
        *(.dma_buf*)
    } > RAM
}

嗯，这里要注意：ALIGN 关键字确保段按指定边界对齐。DMA 控制器通常要求缓冲区地址对齐到传输宽度，搞错了会触发硬件错误。

4.3.2 内存区域拆分：隔离关键与非关键数据

如果芯片有多个 RAM 区域（比如 TCM、SRAM1、SRAM2），我建议把关键数据（如中断栈、RTOS 内核数据）放到快速内存里，把非关键数据（如日志缓冲区）放到慢速内存里。

MEMORY
{
    TCM   (rwx) : ORIGIN = 0x10000000, LENGTH = 64K
    SRAM1 (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
    SRAM2 (rwx) : ORIGIN = 0x20020000, LENGTH = 128K
}

SECTIONS
{
    .kernel_data :
    {
        *(.kernel_data*)
    } > TCM

    .app_data :
    {
        *(.data*)
        *(.bss*)
    } > SRAM1

    .log_buf :
    {
        *(.log_buf*)
    } > SRAM2
}

这样做的好处是：中断响应更快，因为栈和内核数据在 TCM 里，访问延迟低。日志缓冲区放在 SRAM2 里，即使写爆了也不会影响关键功能。

我的习惯：每次修改链接脚本后，都对比一下新旧 .map 文件。用 diff 工具看差异，能快速发现内存布局的变化。特别是团队协作时，这个习惯帮我避免了好几次内存冲突。

4.4 避坑指南：链接脚本常见错误

链接脚本写错了，后果很严重——轻则程序跑飞，重则烧坏硬件。我把自己踩过的坑整理了一下：

段重叠：两个段被分配到了同一个地址范围。检查 .map 文件，看有没有地址重叠。
对齐错误：某些架构要求段对齐到 4 字节或 8 字节边界。忘了加 ALIGN，程序可能异常。
LMA/VMA 混淆：.data 段的 LMA 和 VMA 不同，启动代码必须正确拷贝。我见过有人把 LMA 当 VMA 用，结果数据全读错了。
内存溢出：段的总大小超过了 MEMORY 区域定义的长度。链接器会报错，但有时候错误信息不明显。

我曾经犯过的错：在一个 STM32 项目里，我把 .text 段放到了 RAM 里，忘了改 LMA。结果程序烧录后，一上电就跑飞了。查了两天才发现，是链接脚本里把 Flash 和 RAM 的地址写反了。从那以后，我每次写链接脚本都会反复核对芯片手册上的地址。

4.5 知识结构：链接脚本与内存映射的核心逻辑

为了让你更直观地理解整个过程，我画了一张图：

这张图展示了从源文件到最终可执行文件的完整流程。链接脚本是输入规则，链接器根据规则工作，最终生成 .elf 和 .map 两个输出。你想想看，如果没有链接脚本，链接器就不知道代码该放哪里，那整个系统就是一团乱麻。

4.6 总结：静态内存分配的核心要点

静态内存分配的精髓，就是“在编译时把一切安排好”。链接脚本和内存映射文件，就是实现这个目标的两大工具。我个人觉得，掌握它们的关键在于：

理解 MEMORY 和 SECTIONS 命令：这是链接脚本的骨架。
学会读 .map 文件：它能告诉你内存的真实使用情况。
善用自定义段和内存区域拆分：这是优化内存布局的利器。
养成检查 .map 文件的习惯：每次编译完都看一眼，能避免很多坑。

说白了，静态内存分配就是“一次规划，终身受益”。虽然前期花点时间写链接脚本、分析 .map 文件，但换来的是运行时的高效和稳定。这笔账，怎么算都划算。