📚 课程目录第3章链接器原理

3、链接器原理：链接器的工作机制、符号解析、重定位、垃圾回收（--gc-sections）等核心概念

在TFLite Micro的编译体积优化中，链接器是决定最终二进制大小的“总装车间”。编译器将每个源文件翻译成独立的机器码目标文件（.o），但这些文件彼此孤立，内部引用的函数地址、全局变量位置都是“悬空”的。链接器的职责就是将这些碎片化的目标文件按照链接脚本的规则缝合为一个可执行映像，同时完成符号解析、重定位和段合并。理解链接器的工作机制，是掌握--gc-sections、函数级节（function-sections）等优化手段的前提。本章将深入剖析链接器的核心原理，并展示如何利用这些原理精准削减TFLite Micro的二进制体积。

3.1 链接器的工作机制：从目标文件到可执行映像

链接器（Linker）的输入是编译器或汇编器生成的目标文件（ELF格式，在嵌入式领域常为.axf或.elf）。每个目标文件内部包含多个节（Section）：.text存放可执行指令，.data存放已初始化的全局变量，.bss存放未初始化的全局变量，.rodata存放只读常量。此外还有符号表（Symbol Table）和重定位表（Relocation Table）。链接器的核心工作分为三个阶段：

符号解析（Symbol Resolution）：将目标文件中对函数和变量的未定义引用（undefined reference）与其它目标文件中的全局定义（global definition）进行匹配。例如，micro_interpreter.o调用了AllocateTensor函数，链接器必须在memory_planner.o中找到该函数的实现地址。若找不到，则报“undefined reference”错误；若找到多个同名定义，则报“multiple definition”错误。
重定位（Relocation）：目标文件中的指令使用的是相对虚拟地址（RVA），即相对于本目标文件起始位置的偏移。链接器需要将这些RVA修正为最终的运行时地址。例如，一条BL（分支链接）指令在目标文件中可能写的是“跳转到偏移0x100处”，链接器需要根据该函数在最终映像中的实际地址，重新计算跳转偏移量。
段合并与布局（Section Merging & Layout）：将所有目标文件中同名的节合并为一个大节，并按照链接脚本（Linker Script）指定的内存区域（如FLASH、RAM）分配地址。最终生成一个连续的二进制映像，烧录到MCU的Flash中。

在TFLite Micro的编译中，链接器处理的输入可能多达数百个目标文件。每个算子（如Conv2D、DepthwiseConv2D）通常对应一个独立的.o文件，而all_ops_resolver.o会引用所有算子的注册函数。这就导致了一个关键问题：即使最终模型只用了3个算子，链接器也会将所有算子目标文件拉入链接过程，因为all_ops_resolver的符号表里包含了全部算子的引用。

关键认知：链接器默认的“贪婪”行为是：只要一个目标文件被链接进来，该文件中的所有节（包括未使用的函数）都会被保留。这正是TFLite Micro体积膨胀的根源之一。

3.2 符号解析与重定位的细节：为什么未使用代码难以自动剔除

符号解析遵循“引用-定义”匹配规则。以TFLite Micro的算子注册为例：

// all_ops_resolver.cc 中的典型代码
TfLiteRegistration* Register_CONV_2D() { return &conv2d_registration; }
TfLiteRegistration* Register_DEPTHWISE_CONV_2D() { return &depthwise_conv2d_registration; }
// ... 注册了50+个算子

// 在 AddAllOps() 中：
void MicroMutableOpResolver::AddAllOps() {
  AddBuiltin(BuiltinOperator_CONV_2D, Register_CONV_2D());
  AddBuiltin(BuiltinOperator_DEPTHWISE_CONV_2D, Register_DEPTHWISE_CONV_2D());
  // ... 每个算子都调用对应的Register函数
}

当链接器处理all_ops_resolver.o时，它看到该目标文件引用了Register_CONV_2D、Register_DEPTHWISE_CONV_2D等所有注册函数。这些注册函数定义在各自的算子目标文件中（如conv2d.o、depthwise_conv2d.o）。链接器为了满足这些引用，必须将conv2d.o、depthwise_conv2d.o等全部拉入链接。而每个算子目标文件内部，除了注册函数外，还包含该算子的内核实现（kernel），例如Conv2D()函数、EvalFloat()函数等。这些内核函数可能占用数KB的Flash空间。

更糟糕的是，即使某个算子（如TRANSPOSE_CONV）在最终模型中从未被使用，只要all_ops_resolver.o中调用了它的注册函数，链接器就会保留该算子的全部代码。这就是“链接依赖”导致的体积膨胀。

重定位过程进一步加剧了这个问题。在ARM Cortex-M架构中，函数调用通常使用BL指令，其偏移量范围是±16MB。链接器在重定位时，如果发现某个函数被引用了，就会将其地址写入指令的立即数字段。如果该函数未被引用，则不会触发重定位，但该函数所在的节仍然会被保留在输出文件中——除非显式告知链接器丢弃它。

3.3 垃圾回收（--gc-sections）：链接器的“瘦身手术”

--gc-sections是GNU链接器（ld）提供的一个选项，其全称是“Garbage Collection of Unused Sections”。它的工作原理是：

链接器首先确定根节点（Roots）：通常包括入口点（如Reset_Handler）、中断向量表、以及链接脚本中显式标记为KEEP的节。
从根节点出发，遍历所有节的重定位信息，构建一张引用图（Reference Graph）。如果节A中的代码引用了节B中的符号，则A→B存在一条边。
链接器标记所有从根节点可达的节为“活跃”（Live），其余节视为“死节”（Dead），并从最终输出中剔除。

要启用该功能，需要配合编译选项-ffunction-sections和-fdata-sections。这两个选项告诉编译器：将每个函数放在独立的节中（而不是将所有函数放在同一个.text节中），将每个全局变量放在独立的节中。这样，链接器才能以“函数粒度”或“变量粒度”进行垃圾回收。如果没有这两个编译选项，--gc-sections只能丢弃整个目标文件，而无法丢弃目标文件内部的单个函数。

编译/链接选项	作用	对TFLite Micro的影响
`-ffunction-sections`	每个函数生成独立的`.text.funcname`节	允许链接器丢弃未使用的算子内核函数
`-fdata-sections`	每个全局变量生成独立的`.data.varname`节	允许丢弃未使用的常量表、权重缓冲
`--gc-sections`	链接时删除未被引用的节	从根节点（入口点）出发，剔除死代码
`-Wl,--print-gc-sections`	打印被删除的节名称	用于验证哪些算子被成功剔除

重要前提：如果代码中使用了函数指针或间接调用（如通过TfLiteRegistration结构体中的invoke函数指针调用算子内核），链接器可能无法静态解析这些引用。此时，即使启用了--gc-sections，链接器也会保守地保留所有可能被调用的函数。TFLite Micro的算子注册机制正是通过函数指针间接调用内核的，因此需要额外处理（如使用__attribute__((used))或自定义链接脚本）。

3.4 实战案例：通过链接器原理削减TFLite Micro体积

假设一个智能门锁项目，使用TFLite Micro部署唤醒词检测模型，模型仅包含DepthwiseConv2D、AveragePool2D和FullyConnected三个算子。初始编译后，固件体积为182KB（Flash占用）。通过arm-none-eabi-size工具查看，发现.text段占用了145KB，远超预期。

分析过程：

使用arm-none-eabi-nm列出所有符号，发现conv2d.o、transpose_conv.o、lstm_eval.o等大量算子目标文件被链接进来。
检查all_ops_resolver.o的符号表，确认它引用了所有算子的注册函数。
初步尝试添加-ffunction-sections -fdata-sections -Wl,--gc-sections，但体积仅减少到171KB，效果有限。

关键发现：通过-Wl,--print-gc-sections输出，发现transpose_conv.o中的Eval()函数被删除了，但conv2d.o中的EvalFloat()和EvalInteger()都被保留。原因在于：conv2d.o的注册函数Register_CONV_2D()返回的TfLiteRegistration结构体中，invoke字段指向了EvalFloat，而EvalFloat内部又调用了EvalInteger（用于量化推理）。由于链接器无法确定运行时使用的是浮点还是整数路径，它保守地保留了所有可能的分支。

解决方案：

在conv2d.cc中，将EvalInteger和EvalFloat分别用__attribute__((weak))声明，并在注册函数中根据kTfLiteInt8类型动态选择。但更彻底的方法是：在编译时通过宏TF_LITE_DISABLE_FLOAT排除浮点实现。
修改all_ops_resolver.cc，使用#ifdef条件编译，仅注册模型实际需要的算子。例如：

// 在 all_ops_resolver.cc 中
void MicroMutableOpResolver::AddAllOps() {
  AddBuiltin(BuiltinOperator_DEPTHWISE_CONV_2D, Register_DEPTHWISE_CONV_2D());
  AddBuiltin(BuiltinOperator_AVERAGE_POOL_2D, Register_AVERAGE_POOL_2D());
  AddBuiltin(BuiltinOperator_FULLY_CONNECTED, Register_FULLY_CONNECTED());
  // 不再调用 Register_CONV_2D() 等未使用算子的注册函数
}

重新编译，并添加-Wl,--gc-sections。此时链接器发现conv2d.o的注册函数不再被引用，整个目标文件被丢弃。

结果对比：

优化步骤	.text 段大小	总Flash占用	说明
初始编译（无优化）	145KB	182KB	所有算子全部链接
仅加 --gc-sections	134KB	171KB	丢弃了部分未引用的辅助函数
条件编译 + --gc-sections	68KB	105KB	未使用的算子目标文件整体被剔除

复盘经验：链接器的垃圾回收并非万能。它只能处理“静态可解析”的引用关系。对于通过函数指针、虚函数表或反射机制调用的代码，链接器会保守保留。因此，在嵌入式场景中，最有效的体积控制手段是从源头减少引用——即通过条件编译或配置宏，让链接器根本看不到未使用算子的注册函数。

工程建议：在TFLite Micro项目中，始终开启-ffunction-sections -fdata-sections -Wl,--gc-sections。同时，使用MicroMutableOpResolver而非AllOpsResolver，并显式添加模型所需的算子。对于必须保留但未被静态引用的函数（如中断处理函数），使用__attribute__((used))或链接脚本中的KEEP()指令。

3.5 常见误区与总结

误区一：认为--gc-sections可以删除所有未使用代码。实际上，它只能删除“未被引用”的节，而无法处理通过指针间接调用的代码。TFLite Micro的算子注册机制正是典型的间接调用场景。
误区二：忽略编译选项的配合。没有-ffunction-sections，链接器只能丢弃整个目标文件，粒度太粗。必须同时开启编译和链接选项。
误区三：依赖链接器清理，而不修改源码。最有效的体积优化是在源码层面移除未使用的注册函数，让链接器“看不到”这些符号。
误区四：忘记检查链接映射文件（.map）。通过.map文件可以精确查看每个节的来源和大小，是定位体积膨胀的必备工具。

总结而言，链接器是TFLite Micro体积优化的最后一道关卡。理解符号解析的“引用-定义”规则、重定位的地址修正机制，以及--gc-sections的引用图遍历原理，能够帮助开发者精准定位哪些代码被保留、哪些被丢弃。在实际项目中，应综合运用条件编译、函数级节和垃圾回收，才能将固件体积压缩到极致。