4、链接器基础：链接器的作用、链接脚本、符号解析、重定位、以及静态链接与动态链接的区别

在TVM Micro端侧代码体积优化中，链接器（Linker）往往是被忽视却至关重要的环节。编译器将C/C++源码翻译为可重定位的目标文件（.o），而链接器则负责将这些目标文件与库文件组合成最终可执行的固件镜像。对于资源受限的微控制器（MCU）环境，链接器的行为直接决定了代码段（.text）、数据段（.data）、BSS段（.bss）的最终布局与大小。理解链接器的工作原理，是进行代码体积裁剪、段合并、垃圾回收（--gc-sections）以及自定义链接脚本的前提。本章将系统讲解链接器的核心机制，并重点剖析静态链接与动态链接在嵌入式领域的适用性差异。

4.1 链接器的作用与核心职责

4.1.1 核心原理：从目标文件到可执行镜像

编译器将每个源文件编译为独立的目标文件（ELF格式），其中包含机器指令、数据、符号表以及重定位信息。链接器的主要职责包括：符号解析（将符号引用与定义关联）、段合并（将多个目标文件的同类型段合并）、地址分配（为每个段和符号分配最终虚拟地址/物理地址）、重定位（修正指令中的地址引用）。在MCU场景中，链接器还负责生成中断向量表、初始化堆栈指针等启动时必需的布局。

4.1.2 判断方法：如何分析链接器的工作状态

在TVM Micro工程中，可通过以下方式观察链接器行为：

• 使用 arm-none-eabi-objdump -h firmware.elf 查看各段的大小与加载地址。
• 使用 arm-none-eabi-nm -S --size-sort firmware.elf 按符号大小排序，定位体积大户。
• 使用 arm-none-eabi-ld --verbose 查看默认链接脚本，或通过 -Wl,-Map=output.map 生成映射文件，分析段布局与符号地址。

4.1.3 案例拆解：一次典型的链接过程

假设TVM Micro推理引擎包含 main.o、tvm_runtime.o、ops.o 三个目标文件。链接器首先读取每个文件的节（section）信息，将 .text 段合并为连续区域，将 .data 段合并并分配RAM地址。若 ops.o 中引用了 tvm_runtime.o 中的 TVMGraphExecutor::Run() 函数，链接器需在符号表中找到该符号的定义地址，并回填到 ops.o 中对应的调用指令处。若找不到定义，则报"undefined reference"错误。

4.1.4 常见误区与总结

• 误区1：认为链接器只是简单拼接文件。实际上，链接器需要处理符号冲突、弱符号覆盖、段对齐等复杂逻辑。
• 误区2：忽略链接脚本的重要性。默认脚本可能包含大量调试信息段，导致镜像膨胀。
• 误区3：混淆编译时地址与运行时地址。在MCU中，链接器分配的地址即为最终运行地址（无MMU），因此需确保链接脚本中的FLASH/RAM地址与硬件实际映射一致。

4.2 链接脚本：控制段布局的关键工具

4.2.1 核心原理：链接脚本的语法与作用

链接脚本（Linker Script）使用GNU ld命令语言编写，通过 MEMORY 命令定义目标硬件的存储区域，通过 SECTIONS 命令控制输入段的合并方式、输出段名称、加载地址（LMA）与运行地址（VMA）。对于TVM Micro场景，典型的链接脚本需定义：

MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
  .text :
  {
    KEEP(*(.isr_vector))
    *(.text*)
    *(.rodata*)
    _etext = .;
  } > FLASH

  .data :
  {
    _sdata = .;
    *(.data*)
    _edata = .;
  } > RAM AT> FLASH

  .bss :
  {
    _sbss = .;
    *(.bss*)
    _ebss = .;
  } > RAM
}

4.2.2 操作流程：编写与调试链接脚本

1. 使用 arm-none-eabi-ld --verbose 导出默认脚本作为参考。
2. 根据芯片手册确认FLASH与RAM的起始地址和大小。
3. 在 SECTIONS 中显式放置中断向量表（.isr_vector），并确保其位于FLASH起始地址。
4. 使用 AT> 指定加载地址，实现数据段从FLASH拷贝到RAM的初始化。
5. 通过 _sdata、_edata 等符号，在启动代码中实现数据拷贝和BSS清零。

4.2.3 实战场景：针对代码体积优化的脚本调整

在TVM Micro中，可通过以下脚本技巧减小体积：

• 将 .rodata 中的常量字符串合并到 .text 段，避免额外对齐填充。
• 使用 SUBALIGN(1) 取消段对齐，但需注意部分架构要求指令对齐。
• 将不常用的初始化函数放入 .text.fast 段，通过 --function-sections 配合 --gc-sections 裁剪。

4.2.4 常见误区与总结

• 误区1：忘记在脚本中定义 _estack 等符号，导致启动文件无法正确初始化堆栈指针。
• 误区2：将LMA与VMA混淆，导致数据段初始值未正确从FLASH拷贝到RAM。
• 误区3：使用绝对路径引用库文件，降低脚本可移植性。

4.3 符号解析与重定位

4.3.1 核心原理：符号表与重定位表

每个目标文件包含一个符号表（.symtab），记录全局符号、局部符号及其属性（类型、大小、所在段）。重定位表（.rel.text 等）则记录了需要修正的位置。链接器在符号解析阶段，将每个未定义符号与某个目标文件中的定义符号关联；若存在多个强符号定义，则报多重定义错误。重定位阶段，链接器根据符号的最终地址，修改指令中的立即数或地址字段。

4.3.2 判断方法：常见符号错误分析

4.3.3 案例拆解：重定位导致体积膨胀

在ARM Cortex-M4上，若函数A调用函数B，且两者距离超过BL指令的±16MB范围，链接器会插入一个veneers（跳板）代码段。每个veneers约8字节，当存在大量远距离调用时，会显著增加代码体积。通过 -Wl,--no-orphan-handling 或调整段顺序，可减少veneers数量。例如，将频繁互调的函数放入同一段，或使用 -ffunction-sections 后按调用关系排序。

4.3.4 常见误区与总结

• 误区1：认为重定位只发生在链接阶段。实际上，部分嵌入式系统支持运行时重定位（如动态加载），但MCU中极少使用。
• 误区2：忽略 -fPIC 与 -fPIE 的影响。在MCU中，通常使用绝对寻址，避免位置无关代码带来的额外开销。

4.4 静态链接与动态链接的区别

4.4.1 核心原理：两种链接方式的工作机制

静态链接在构建时将库代码完整复制到可执行文件中，生成独立的固件镜像。其优点是运行时无需外部依赖，启动速度快；缺点是镜像体积大，且库更新需重新链接。动态链接则仅在可执行文件中保留符号引用，运行时由动态加载器（如Linux的ld.so）将共享库映射到进程地址空间。动态链接可显著减小存储占用，但引入运行时开销和依赖管理复杂度。

4.4.2 对比分析：嵌入式场景的适用性

4.4.3 实战场景：TVM Micro为何必须使用静态链接

TVM Micro部署在裸机或RTOS环境，通常不具备文件系统和动态加载器。若使用动态链接，需要实现一个运行时符号解析器，这本身就会消耗大量代码空间（约10-20KB），且引入不可预测的延迟。因此，TVM Micro默认采用静态链接，并通过 --gc-sections、-ffunction-sections 等选项裁剪未使用代码。例如，若模型仅使用卷积和全连接算子，链接器可丢弃其他算子实现，将固件从1MB压缩至300KB。

4.4.4 常见误区与总结

• 误区1：认为动态链接一定比静态链接节省内存。在MCU中，动态链接器的代码和数据结构可能抵消库共享带来的收益。
• 误区2：忽略静态链接中库的裁剪。使用 --whole-archive 会强制链接所有库成员，应谨慎使用。
• 误区3：混淆链接顺序。在GNU ld中，库的顺序影响符号解析，被依赖的库应放在后面。

4.5 本章总结与复盘

链接器是TVM Micro代码体积优化的最后一道关口。通过深入理解符号解析、重定位和链接脚本，开发者可以精确控制固件布局，裁剪冗余代码。静态链接在MCU场景中占据绝对主导地位，但需结合 --gc-sections、函数段划分和链接脚本优化，才能实现极致的体积压缩。在实际项目中，建议建立链接映射文件（.map）的定期审查机制，跟踪各段大小变化，及时发现异常膨胀。