链接静态库为何会破坏C++异常处理机制导致程序终止？

• 静态libcupti带不兼容的栈展开元数据：闭源的libcupti_static.a编译时生成了不符合GCC规范的.eh_frame栈展开段内容，哪怕库内代码完全未被调用，只要该段被合并到最终二进制中，就会破坏全局栈展开索引结构，导致异常抛出时找不到对应的栈展开条目，直接触发栈展开失败调用terminate。
• gold链接器的段合并逻辑缺陷：gold和默认的bfd链接器对静态库未使用段的处理逻辑不同，bfd会自动剔除未引用目标文件的无效栈展开段，而gold要么保留了该类无效段，要么合并时破坏了全局栈展开表的索引顺序，最终导致栈展开流程走到错误分支。

• 对比不同链接方式生成的二进制的栈展开段：执行readelf -WF ./a.out查看输出的FDE（栈展开描述符）条目，异常版本会出现地址范围冲突、或者对应main函数所在地址范围的FDE条目缺失/无效的情况。
• 生成链接映射表对比：编译时添加-Wl,-Map=output.map参数生成链接映射文件，对比gold和bfd链接器分别引入了libcupti_static.a中的哪些目标文件和段，确认gold链接时是否引入了未使用的、带错误元数据的段。
• 验证段裁剪效果：编译时添加-Wl,--gc-sections参数让链接器主动丢弃未使用的段，如果异常消失即可确认是未使用的libcupti段导致的问题。

• 优先使用动态版libcupti：动态库的栈展开段独立加载，不会和主程序的栈展开元数据合并产生冲突，是成本最低的解决方案。
• 若必须使用静态libcupti，可选择切换回默认的bfd链接器，避免gold的段合并缺陷。
• 保留gold链接器的场景下，添加链接参数规避：可添加-Wl,--gc-sections丢弃未使用段，或添加-Wl,--eh-frame-hdr让gold强制生成正确的栈展开头信息，修复索引结构。
• 调整链接顺序：将libcupti_static.a的链接位置放到整个编译命令的末尾，同时添加-Wl,--as-needed参数，让链接器只加载实际用到的libcupti目标文件，减少无效段引入的概率。

内容的提问来源于stack exchange，提问作者Flamefire