3. 链接脚本优化：.ld 文件的结构与段布局

说到编译优化，很多人第一反应是改编译器选项、调优化等级。但说实话，真正决定代码在芯片上怎么放的，是链接脚本。我见过不少项目，编译告警全清、优化等级开到最高，结果跑起来就是不稳定——最后查出来，是链接脚本里段放错了位置，或者填充字节太多，把关键数据区挤爆了。

这一章，我们就来拆解 S32DS 里的 .ld 文件。我会结合我在几个量产项目里踩过的坑，把链接脚本的结构、内存区域定义、段布局优化和减少填充字节这几个点讲透。

3.1 链接脚本的结构解析

一个标准的 .ld 文件，说白了就是告诉链接器三件事：芯片有什么内存、代码和数据要放哪里、最终输出什么格式。它的骨架通常长这样：

/* 1. 架构声明 */
OUTPUT_ARCH(arm)
ENTRY(Reset_Handler)

/* 2. 内存区域定义 */
MEMORY
{
    flash (rx)  : ORIGIN = 0x00000000, LENGTH = 2M
    ram   (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 256K
}

/* 3. 段布局 */
SECTIONS
{
    .text : { *(.text*) } > flash
    .data : { *(.data*) } > ram AT> flash
    .bss  : { *(.bss*)  } > ram
}

嗯，看着简单吧？但实际项目里，这个结构会被各种宏、条件编译、分散加载文件搞得面目全非。我个人习惯，拿到一个新项目的链接脚本，第一件事就是删掉所有注释和条件编译，把 MEMORY 和 SECTIONS 两个块单独拎出来看——这样最清楚。

3.2 内存区域定义：别让芯片白给你空间

MEMORY 块定义了芯片的物理内存资源。我遇到过最典型的错误，就是内存区域定义和芯片手册对不上。比如某款 S32K3 的 RAM 其实分了两块：一块紧贴 CPU 的低延迟 RAM，另一块是总线上的普通 RAM。如果链接脚本里只定义了一个连续的 RAM 区域，那低延迟 RAM 的特性就浪费了。

正确的做法，是把不同特性的内存分开定义：

MEMORY
{
    /* 紧贴 CPU 的低延迟 RAM，放中断向量和关键变量 */
    ram_lowlat (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 32K

    /* 普通总线 RAM，放一般数据和堆栈 */
    ram_general (rwx) : ORIGIN = 0x20000000, LENGTH = 224K

    /* 程序 Flash */
    flash (rx) : ORIGIN = 0x00000000, LENGTH = 2M

    /* EEPROM 模拟区，放校准参数 */
    eeprom (rw) : ORIGIN = 0x10000000, LENGTH = 64K
}

为什么要这么分？因为中断响应时间、DMA 访问延迟、ECC 保护策略，都跟内存区域挂钩。你想想看，如果把一个频繁访问的全局变量丢到普通 RAM 里，每次读写都要多等几个时钟周期——在实时控制里，这就是隐患。

内存区域	典型用途	优化要点
ram_lowlat	中断向量表、RTOS 内核变量、高频访问变量	尽量放 4KB 以内，保证单周期访问
ram_general	堆、栈、普通全局变量	注意对齐，避免跨边界访问
flash	代码、常量、只读数据	考虑代码对齐到 16 字节，提升预取效率
eeprom	标定参数、故障码、配置字	单独段，防止被其他数据覆盖

3.3 段布局优化：让代码和数据各归其位

SECTIONS 块是链接脚本的核心。它决定了 .text（代码）、.data（初始化数据）、.bss（未初始化数据）、.rodata（只读数据）这些段最终落在哪个内存区域，以及它们的排列顺序。

优化的核心思路就两条：减少段间填充、利用缓存局部性。

3.4 减少填充字节：每一字节都珍贵

链接器为了对齐，会在段之间插入填充字节。比如 .text 段结束地址是 0x1001，下一个段 .rodata 要求 4 字节对齐，那链接器就会在 0x1001~0x1003 填充 3 个字节的 0x00 或 0xFF。小项目无所谓，但在 Flash 只有 256KB 的 MCU 上，这些填充字节累积起来可能吃掉好几 KB。

怎么减少？我总结了三个实用方法：

1. 调整段顺序：把对齐要求相同的段放在一起。比如 .text 和 .rodata 都是 4 字节对齐，那就让它们相邻，避免中间插入对齐要求不同的段。
2. 使用 SUBALIGN：在 SECTIONS 块开头设置 SUBALIGN(4)，让所有段默认按 4 字节对齐，减少因对齐不一致产生的填充。
3. 手动对齐关键段：对于中断向量表这类必须对齐到 256 字节或 512 字节的段，用 . = ALIGN(256); 显式指定，避免链接器自动插入过多填充。

SECTIONS
{
    /* 设置全局子对齐为 4 字节 */
    . = ALIGN(4);
    __text_start = .;

    .text : { *(.text*) } > flash

    /* 让 .rodata 紧跟在 .text 后面，减少填充 */
    .rodata : { *(.rodata*) } > flash

    /* 显式对齐中断向量表 */
    . = ALIGN(256);
    .isr_vector : { *(.isr_vector*) } > flash

    /* 数据段，运行时在 RAM，加载时在 Flash */
    .data : { *(.data*) } > ram AT> flash
    __data_load = LOADADDR(.data);
    __data_start = ADDR(.data);
    __data_end = ADDR(.data) + SIZEOF(.data);

    /* BSS 段，运行时清零 */
    .bss : { *(.bss*) } > ram
    __bss_start = ADDR(.bss);
    __bss_end = ADDR(.bss) + SIZEOF(.bss);
}

你看，这里我用了 __data_load、__data_start、__data_end 这些符号。它们不是链接脚本的关键字，而是我手动定义的符号，供启动代码在初始化时把 .data 段从 Flash 拷贝到 RAM。这是嵌入式开发的经典做法，但很多人容易漏掉 __data_load 的定义——没有它，启动代码就不知道数据在 Flash 里的起始地址。

3.5 链接脚本优化前后对比

下面这张 SVG 图，展示了我之前优化一个 S32K344 项目链接脚本前后的段布局变化。你可以直观地看到填充字节是怎么被压缩的。

3.6 实战建议：链接脚本优化的检查清单

最后，我把自己在项目里用的检查清单分享出来。每次改完链接脚本，我都会逐条过一遍：

• 内存区域定义是否准确？——对照芯片手册，确认 ORIGIN 和 LENGTH 无误，特别是不同 RAM 区域的地址范围。
• 段顺序是否合理？——把对齐要求相同的段排在一起，减少填充。
• 关键段是否显式对齐？——中断向量表、DMA 描述符表等，用 ALIGN() 强制对齐。
• 是否有未使用的段？——用 --gc-sections 链接选项配合链接脚本，剔除未引用的段。
• 加载视图和运行时视图是否匹配？——检查 AT> 指令，确保 .data 段的加载地址和运行地址正确。
• 符号定义是否完整？——启动代码需要的 __data_load、__data_start、__data_end、__bss_start、__bss_end 等符号必须存在。