有阵子排查某个“某跨平台模块”的构建异常时我发现一个现象两个源文件都包含了同一个模板实例链接器居然没有报“multiple definition”最终产物里也只有一个副本。另一处某段被垃圾回收的代码害得程序运行时丢失了一整块全局数据原因却不在编译器优化而是出在ELF对象文件里一个很少被讨论的结构——节组section groups。也是在那个时候我第一次认真把readelf -g的完整输出从头读了一遍。节组这个概念底层链接器、编译器和 ELF 规范天天在用但很多写得再熟练的开发者也没真正看过SHT_GROUP的样子。这篇文章就围绕readelf -g这个选项展开先讲节组解决了什么问题再拆解 ELF 规范中的SHT_GROUP结构然后分析readelf -g每一列含义最后结合链接器垃圾回收、COMDAT 合并和实际排查经验把它彻底说透。想深入了解 ELF、研究二进制体积、或者写静态分析工具的人这篇尤其适用。1. 从一次诡异的链接现象说起节组到底解决了什么问题很多问题表面上是链接错误本质上是 ELF 结构设计的问题。我第一次对节组产生兴趣就是因为一个“本应冲突却完全不冲突”的例子。假设有两个 C 编译单元都实例化了同一个模板函数传统模型下模板函数会产生一个强符号强符号在多个源文件里出现就应该引起重复定义对吧但实际项目里只要模板实例相同、实现相同链接器不仅不会报错还会很“聪明”地只留下一份代码。这让不少第一次接触的人摸不着头脑难道链接器会自己对比每个符号的内容发现一样就默认合并没那么高级。这套去重能成立是因为每个编译单元在生成目标文件时把同一个模板实例的代码放进了一个节组里组里的签名符号就是模板实例化后的符号名。链接器遇到多个具有相同签名的 COMDAT 节组时不把它们当作冲突而是当作候选副本保留任意一个丢弃其余所有。所以程序最终只有一个副本地址也被重定位到正确位置。1.1 C 模板重复代码为什么不会报 multiple definition模板在 C 里几乎是强制在每个使用它的编译单元中实例化一份的。为了不把这种重复变成致命错误业界在 ELF 里定了一组规则每个相关代码节都挂进同一个组组上打一个GRP_COMDAT标志并指定一个签名符号。签名符号就是组“对外宣称的身份”。链接器只要发现两个组签名一致、且标志允许 COMDAT 合并就只取其一。用readelf -g看一个编译产物你能直接在输出里看到这个签名符号和成员节列表。比如一个模板函数foo你会在输出里看到类似这样的结构Section group section .group [0x3]: [0] .text._Z3foov意思是.text._Z3foov这个节属于一个组组长由组节本身承载组外身份则是符号_Z3foov。链接器处理多个目标文件时遍历这些组并去重用户层面的表现自然就是“多份相同模板只保留一份”。1.2 弱符号与节组的边界差异有些开发者会把节组去重和弱符号去重混为一谈但它们其实是两套机制。弱符号weak symbol允许一个符号在多个输入目标文件里被重复声明链接器默认选择一个强符号若没有强符号就随便选一个弱定义。弱符号强调的是“这个符号可以被覆盖”它并不维护一个明确的一致性集合。节组则强调整体的原子性组内包含的节要么一起留下要么一起丢弃不允许缺斤短两。假设一个模板函数实现附带了一份静态局部变量数据静态局部变量往往会被分配到.data节里的一个独立子节。如果只把函数代码定义为弱符号、静态变量不跟着走那么多个弱定义共存时代码可能被重定位到一份数据却还留着好几份程序状态一旦激烈切换就可能错乱。而把函数节和数据节放进同一个节组后链接器会保证整个集合成为一个不可分割的单位不会出现“代码用了副本 A静态数据却保留了副本 B”的混搭状态。这里两者的差异可以用下面这组特性对比来理解特性弱符号节组 / COMDAT去重单元单个符号一组节冲突容忍允许重复定义允许签名相同的 COMDAT 重复原子性无组内节同生共死典型用途库函数覆盖、默认实现C 模板、内联函数、类型信息检查工具nm -C/readelf -sreadelf -g明白了这两者的差异再回头看奇怪链接现象很多问题就能快速归类了。2. ELF 里 SHT_GROUP 的结构、标志与成员节归属节组不是某家公司自造的扩展它是 ELF 规范里的正式成员。规范中定义了专门的节类型SHT_GROUP对应的数值是 9。之前你用readelf -S看节头表可能会偶尔看到类型名为GROUP的节那就是节组本身。2.1 组节本身的物理布局SHT_GROUP这个节的内容不是普通字节流而是一个 32 位整数的数组。数组第一个条目是组的“标志字”目前最重要的标志就是GRP_COMDAT值为 1。如果标志字里这个位被置上链接器就知道“这个组可以参与跨目标文件的重复副本消除”。从第二个 32 位条目开始每个值都是本目标文件内的一个节头索引代表该组的成员节。换句话说组节自身就是一份成员名单。需要特别注意的是这份名单不是简单地把节名写成字符串而是直接用节索引数值来引用。为什么用索引因为 ELF 文件在重定位阶段非常频繁地把“某一节”作为依赖对象直接索引比字符串查找更快也更稳定。组内第几个成员、组外成员节如何对应都可以通过索引精确对齐。一个典型的组节内容用十六进制展开后大概长这样0x00000000: 00000001 00000004 00000005 00000000第一个 32 位值是1表示这是一个 COMDAT 组后面两个值4和5是成员节头索引说明这个组内有两个节索引分别是 4 和 5。真实文件里节头索引一般以 1 开始0 是空节所以看到 4、5 很常见。2.2 成员节上的 SHF_GROUP 归属标记除了组节自己保存成员名单ELF 还在成员节身上额外打了一个标记节头 flags 里的SHF_GROUP对应值0x200。也就是说一个节如果想表明“我隶属于某个组”它自己也得把SHF_GROUP位打开。这看起来像重复信息存储但实际设计是有目的的。组节保存的是完整的成员索引列表负责链接器遍历时的整体调度而每个成员节自己的SHF_GROUP标记让那些不直接解析 SHT_GROUP 的通用工具也能一眼看出这个节不是一个自由节。对你没有看错这确实是冗余设计中的典型。以重定位节为例.rela.text.foo常常并不在组节的成员列表里但它负责修正的目标节却是组成员。负责拆解二进制分析的工程师需要记住组节是一等公民成员节通过SHF_GROUP与组绑定而重定位节和组成员之间的对应关系则要靠重定位节头里的sh_info字段去推导。2.3 签名符号与符号表索引SHT_GROUP节点的sh_link字段指向一个符号表sh_info字段则表示该符号表中的具体符号索引。这个被索引符号的名字才是组对外使用的“签名”。链接器看到两个文件名、两组内容完全不同的 COMDAT 组时并不比较节内容而是比较签名符号。如果签名符号的名字相同就认为这两个组是同一个“逻辑对象”的重复副本可以合并。签名符号不要求一定是一个全局可见符号甚至可以是局部符号但实际场景中绝大多数签名符号就是模板化后的函数名或类型名。这带来一个有意思的排查方向假如某个 COMDAT 去重没有生效你用readelf -s去看组签名符号会发现它的符号索引、作用域或者绑定属性可能和预期不一致。正常情况下编译器会为模板实例生成全局、默认可见或隐藏的合适符号作为签名一旦这种设置不对链接器就不再认为它们是同一个组。3. readelf -g 实战输出逐字段解读与手工复现命令本身很简单readelf -g test.o # 等价写法 readelf --section-groups test.o难的是把输出和 ELF 规范对应起来。这一节我带你从零构造一个带节组的目标文件然后逐条解释输出。3.1 先造一个带节组的 .o 文件直接用汇编器创建节组是最直接的方式。下面这段汇编会生成一个名为foo的 COMDAT 组组内包含一个代码节和一个数据节.section .text.foo,axG,progbits,foo,comdat foo: ret .section .data.foo,awG,progbits,foo,comdat foo_data: .long 1对不熟悉汇编语法的读者解释一下.section后面的第一个参数是节名引号里的a表示可分配、x表示可执行、w表示可写、G表示属于某个节组progbits表示这个节含有实际程序数据后面的foo是组签名符号最后的comdat关键词告诉汇编器这里要生成 COMDAT 节组。把这个文件交给汇编器汇编后运行readelf -S test.o你会看到节头表里多了一个类型为GROUP的节通常名字是.group。随后运行readelf -g test.o输出大概是这样的Section group section .group [0x3]: [0] .text.foo [1] .data.foo[0x3]是组节自身的节头索引。输出虽然简洁但信息量不小组节叫.group类型是SHT_GROUP它下面挂了两个成员节.text.foo和.data.foo。由于我们用汇编指令显式指定了comdat这两个成员组成的 COMDAT 组会一个不落被拆到主节表里。3.2 逐字段解读 readelf -g 输出第一行Section group section .group [0x3]节点名和节索引。第二行到后续行是组内成员节列表。这里的顺序和你组节内容里保存的节头索引顺序完全一致。之前我们说过组节内容是一个 32 位整数数组第一个数字是标志后面的数字就是成员索引readelf -g把这些索引翻译回了人类可读的节名。如果在组节里有签名符号部分版本还可能会显示类似with signature symbol foo这样的字段。并不是每个版本都会把签名打出来因为sh_link和sh_info指向的符号表信息在通用显示时经常被省略。这时你可以用readelf -g -s test.o同时查看符号表找到组签名对应的符号定义。需要注意有些版本只会在本节不属于 COMDAT 时才额外打印警告。3.3 对照组节原始字节为了让概念更扎实用readelf -x .group直接展开组节的十六进制内容readelf -x .group test.o你会看到第一个 32 位整数是0x00000001这就是GRP_COMDAT标志。接下来的一串整数和组内成员节索引一一对应。假设输出中看到0x00000000: 00000001 00000002 00000005 00000000含义就是组标志为 1第一个成员节索引是 2第二个成员节索引是 5。和readelf -g输出的成员节名称数量对得上就说明节组结构是良构的。后续若有一个链接器对节组处理异常这个十六进制视角能帮你判断是不是标志字被意外改写。3.4 别把 readelf -g 和调试选项搞混一个很容易被绕进去的点是在别的工具里-g常常代表“调试信息”。比如objdump -g显示的是调试段相关内容gcc -g表示生成调试信息。而在readelf里-g的默认含义就是--section-groups只用于展示节组信息。假如你本来想看 DWARF 调试信息跑到readelf里打-g只会得到节组列表甚至因为目标文件没有节组而直接返回空非常容易误判。所有我实际排查时更推荐写全长期选项readelf --section-groups test.o readelf --debug-dumpinfo test.o这样一眼就能看出你到底在查节组还是查调试信息。4. 链接器眼中的节组保留、丢弃、垃圾回收的最小单元理解节组结构只是第一步真正和日常开发挂钩的是链接器如何使用它。节组在链接器里主要影响三件事垃圾回收、重复消除、重定位一致性。4.1 节组是 --gc-sections 下绝对不可拆的原子单元现代可执行文件为了压缩体积常用--gc-sections来做段级垃圾回收。它的原则是从入口点和导出符号出发沿着重定位关系图把“被引用到的节”留下没被引用到的节直接丢弃。问题在于重定位关系并不总是覆盖所有强耦合数据。一个常见现象是函数代码通过重定位引用某个数据结构但数据结构本身没有反向引用函数。如果链接器单独判断每个节能否丢弃就可能把函数留下、数据丢掉或者反过来最后生成一个链接成功但运行即崩溃的怪物。节组把这种问题消灭在架构层如果某个节属于一个组链接器会把整个组当作一个不可分割的节点来做可达性分析。组内任何一个成员被引用所有成员都保留组没有任何成员被外部引用整个组连同内部所有节一起清除。例如我们的.text.foo和.data.foo被放在同一个组里。只要某个重定位引用了.text.foo中的入口.data.foo就不会被扔掉因为链接器已经把它们绑定为同一个“生存单元格”。4.2 COMDAT 重复消除的典型过程在链接多个可重定位目标文件时COMDAT 组的处理顺序一般是这样链接器读取第一个目标文件遇见一个SHT_GROUP记录其签名符号和成员索引。读取第二个目标文件遇到相同签名的 COMDAT 组。比较组标志和签名如果都匹配就选定第一个组作为保留组第二个组的成员节全部丢弃但保留组的符号表项仍然继续承担重定位解析。所有对丢弃节的重定位都转而指向保留组的对应符号。这个机制是模板代码能大规模去重的基础。同一份std::vectorT代码就算被 100 个编译单元实例化在链接最终镜像时也只会留下 1 份实现。如果整个工程里没有任何模板、内联函数节组可能永远不出现这也是为什么不少人写了很多年代码却没见过SHT_GROUP。4.3 为什么可执行文件里很少看到节组readelf -g平时不怎么有用一个主要原因是链接完成后的可执行文件或共享库绝大多数情况下已经不存在 COMDAT 节组了。因为重复消除在链接过程中已经做完保留组变成普通节组节本身不再具有调度价值链接器会顺手把它去掉。所以如果你拿着一个编译好的可执行文件执行readelf -g看到“没有节组”或空输出完全正常。真正该查节组的场景是静态库中间文件、可重定位目标文件.o以及某些没有完全合并的链接产物。负责做固件镜像分析的工程师尤其要注意有些嵌入式链接脚本会保留输入节组以便后续再次连接。这个时候可执行文件的节头表里还可能出现 GROUP 类型节而阅读readelf -g的输出基本等同于阅读链接器的中间调度结果。5. 实际排查心得与工具链经验节组很少单独出问题但一旦出问题表现往往非常晦涩。我在这里记录几个亲身验证过的排查场景供读者参考。5.1 垃圾回收后静态数据丢失的经典现场某次项目里可执行文件体积优化后运行时偶发崩溃现象集中在某个模板类静态成员上。代码明明初始化了静态数据运行到某条路径时读取却是 0。用调试器看符号表静态变量符号还在地址也有效但实际数据被清零或指向了问号区域。我当时的第一反应是查.data节是否被--gc-sections误伤。但readelf -S显示数据节确实存在。事情真正明朗是在我把链接器的--print-gc-sections日志打开后那个静态变量所在的节根本没有被算作“被引用”因为引用它的代码在另一个 COMDAT 组里链接器认为整组都被丢弃了。换句话说模板函数实例 A 属于组 X模板函数实例 B 属于组 YX 和 Y 都被外部引用但链接器在排除重复时把 X 丢了。丢失 X 时静态变量节因为跟着 X 的同组关系一起被丢弃可调试符号却残留了下来。最终残余符号和解引用错位让调试器看起来像“数据还在但值丢了”。这个案例给我的教训是优化体积的项目务必保留--print-gc-sections日志发现某个物理地址能解析到符号但行为异常时立刻用readelf -g看所属组。5.2 不同链接器对节组重复组的处理并不完全一致在多个工具链并存的环境里节组的兼容性也值得关注。我的经验是大多数现代链接器都会严格按 COMDAT 规则合并但它们对下列细节的处理有差异处理场景链接器行为可能差异非 COMDAT 组的同名重复某些链接器直接报错某些选择合并组内出现重复节名可能引发未知段序变化重定位节是否随组原子回收某些链接器会把重定位节额外排除在组外组签名符号为弱符号去重稳定性受符号绑定影响遇到跨工具链构建时我建议把“节组是否存在”当作一项常规验证项纳入构建脚本或持续集成。最朴素的办法就是批量扫描for f in build/**/*.o; do echo $f readelf --section-groups $f done如果你在某个中间产物中发现了节组但没有发现签名符号或者成员节数量异常第一时间先去看是不是剥壳、重命名或手工 patch 导致节组元数据损坏。5.3 组合使用 readelf 选项确认组完整状态单看readelf -g不够最好把它和另外几个视图拼起来。我的习惯顺序是readelf -h确认文件类型是REL还是EXEC/DYN决定该不该期待节组。readelf -S找到所有类型为GROUP的节并记录节索引。readelf -g列出每个组的成员和签名信息。readelf -x 组节名展开组节原始数据验证标志字和成员索引数组。readelf -s检查签名符号的绑定和索引。配合这五个命令一个目标文件里的节组是否完整、是否会被链接器正确消费基本能形成完整闭环。遇到某些符号“若隐若现”的离奇错误时这组命令比单纯看nm输出有用得多。5.4 一个小脚本思路把签名符号和组内节名拉平输出最后分享一个很轻的实践技巧。在为某次静态库瘦身做分析时我写了一个小循环脚本把每个.o文件的节组信息拉平成“签名符号、成员节”的表格数据for f in lib/*.o; do sig$(readelf -g $f 2/dev/null | grep -oP signature symbol \K[^]) mems$(readelf -g $f 2/dev/null | awk /\[[0-9]\]/{print $2} | tr \n ) [ -n $mems ] echo $sig - $mems done这个思路不复杂但在统计重复组数量、寻找异常超大组时非常管用。后来我再遇到“链接后代码体积应该小却没小”的谜题第一反应就是先跑这类扫描把重复 COMDAT 组找出来再根据成员节名推算出是哪个模板或内联函数膨胀了。最后再分享一个工具使用细节实际使用中readelf -g的输出版本差异比想象中大有些 binutils 版本会把签名符号另起一行显示有些版本则直接并进组节标题行极少数版本对SHT_GROUP节的十六进制展开会忽略 8 字节对齐让你误以为成员索引多了一个。我的习惯是碰到版本敏感的输出格式时不要只依赖-g这种短选项输出而是同时打开-S对照节索引再用-x看原始字节三个视图相互印证就不会被格式波动带偏。如果你还想更进一步可以试试比较使用和不使用--gc-sections两种链接方式下最终可执行文件里的节表。你会发现带节组的中间对象在链接前的节表复杂得多链接后的节表往往干净得像什么都没发生过。正是这种“隐藏起来但一直在起作用”的结构让节组始终值得我们在排查时多看它两眼。