mold 插件系统拆解LTO、自定义符号处理如何在链接阶段插一脚【免费下载链接】moldmold : A Modern Linker in Rust 项目地址: https://gitcode.com/GitHub_Trending/mo/mold链接器在大多数开发者眼里是一个黑盒编译器把.o文件吐出来链接器把符号表拼起来、重定位、输出可执行文件然后收工。但在 mold 的视角里链接过程不是一条单行道而是若干个可以被外部代码介入的时点。当你使用-flto编译时GCC/Clang 会把自己的 IRGIMPLE 或 LLVM bitcode包装进 ELF 文件交给链接器此时链接器必须把编译的活儿重新捡起来而当你使用--wrap、--defsym这类选项时链接器又要在符号解析的关口上动手脚。本文直接进入 mold 源码elf/lto.rs、elf/passes.rs、elf/input_files.rs拆解这些插件到底在哪里、以何种机制介入链接流程。链接主流程插件介入的时间轴先看 mold 的主链接函数 link()它给出了整个过程的骨架解析命令行参数、构建Contextread_input_files()并行读取所有输入文件resolve_symbols()完成第一轮符号解析如果存在 LTO 对象has_lto_obj()为真执行do_lto()remove_unreachable_files()裁剪无用文件解析.eh_frame、.sframe合并 mergeable section应用版本脚本、生成动态符号表、重定位、写输出。注意第 3 步和第 4 步的顺序mold 会先做一次完整的符号解析再决定是否进入 LTO。这是因为 LTO 后端需要知道每个 IR 符号最终被解析成了什么——是常规对象里的定义、DSO 里的定义还是另一个 IR 对象里的定义——才能决定哪些符号可以内联消失、哪些必须保留在输出中。这是整个插件机制的设计核心插件不是旁路而是嵌入在符号解析的中间环节里。read_input_files()对 LTO 对象也做了特殊处理reader.rs并行读文件的循环只记录IR 文件真正的 claim认领动作要等链接脚本解析完之后、按命令行顺序串行地交给 LTO 插件——因为claim_file钩子必须一个文件接一个文件地被调用不能并行。LTO一份 C 回调协议三种介入时点mold 的 LTO 走的是 GCC 定义的linker plugin APIwhopr/driver 协议不是 mold 自己发明的私有接口。onload是一个dlopen出来的 C 函数mold 通过dlopen/dlsym找到它然后塞给它一张transfer vector——一张 tag-value 表lto.rs表中每一项都是一个回调函数指针LDPT_REGISTER_CLAIM_FILE_HOOK注册认领文件钩子插件在这里声明这个 IR 文件我收了这是它的符号表LDPT_REGISTER_ALL_SYMBOLS_READ_HOOK注册所有符号已读完钩子插件在这里把 IR 编译成 ELF 对象LDPT_REGISTER_CLEANUP_HOOK注册清理钩子链接结束后让插件删除临时文件。Hooks结构体lto.rs把这三个钩子原样存下来配合一组全局变量CLAIMED_SYMBOLS插件回传的符号缓冲、CONTEXT插件编译期间指向链接器上下文的原子指针。源码注释点明了原因The plugin isnt thread-safe and keeps global state, so this module does too——插件 API 是单线程的全局状态设计mold 就陪它用全局状态。整个 LTO 数据流分三步与模块头部注释一一对应第一步claim 与符号读取。read_lto_object()调用claim_file钩子插件通过add_symbols回调把符号灌进CLAIMED_SYMBOLS。mold 随后把每个 IR 符号转成 ELF 符号ClaimedSymbol::to_elf_sym定义型符号标为SHN_ABSIR 对象没有 section弱符号标STB_WEAK函数/变量类型、可见性逐一映射。这里有一个细节IR 对象里 COMDAT 成员的comdat_key会被单独记录因为IR 文件没有输入 sectionCOMDAT 语义不能按常规对象的逻辑处理。第二步解析结果回传。所有符号读完并解析好后mold 通过get_symbols把每个 IR 符号的最终解析状态告诉插件lto.rs。状态用LDPR_*常量表达比如LDPR_PREVAILING_DEF_IRONLY只被 IR 对象引用的定义插件可以放心内联掉、LDPR_PREVAILING_DEF被常规对象引用必须留在 LTO 输出里、LDPR_RESOLVED_DYN解析到了 DSO、LDPR_PREEMPTED_REG被常规对象抢先。如果某个文件是归档成员但最终没被选中mold 会把它的所有符号标成LDPR_PREEMPTED_REG让插件忽略它们。第三步编译回填。run_plugin()调用all_symbols_read钩子插件一次性把所有 IR 对象编译成几个大 ELF 文件通过add_input_file回调交回 mold。这些文件被标记为ObjectOrigin::LtoOutput插入到ctx.objs的对应位置随后do_lto()清空符号表、删掉所有 IR 对象、重新做一轮resolve_symbols()——因为 LTO 输出文件的符号和 IR 符号不一样必须重新解析一遍。do_lto()还藏着两个工程细节重复符号预检多个 IR 文件定义同一个符号时LTO 后端会随机选一个而不是报错所以 mold 在调用插件前先check_duplicate_symbols()--wrap联动--wrap指定的符号及其__wrap_*/__real_*变体必须被标记为referenced_by_regular_obj否则 LTO 后端可能把它们内联掉导致包装失效lto.rs。兼容性v0/v1 双 API 与重启退路插件 API 有版本之分GCC 12 和任意版本 LLVM 支持get_symbols_v3API v1老版本 GCC 只有 v0/v1get_symbols_v1/v2。mold 在get_api_version回调里声明自己支持到LAPI_V1并在 transfer vector 里同时注册 v2/v3 两个版本的回调运行时再决定用哪个。老版本 v1/v2 API 有个致命缺陷没有提供忽略之前传给插件但最终没被选中的归档成员的接口。mold 的应对是restart_process()lto.rs——自己重启自己把没被选中的 IR 文件通过--:ignore-ir-file...传给新进程加上--:lto-pass2标记execv再跑一遍。源码注释直言This is an ugly hack and should be removed once we drop support for GCC versions older than 12.自定义符号处理--wrap 与 --defsym 的介入点自定义符号处理不是一套新插件框架而是体现在几个命令行选项上。mold 的符号表是个全局哈希表ctx.symbols符号解析的核心规则是按优先级 rank 竞争symbol_resolution_rank普通强定义 rank 最低最优先弱定义其次归档成员/DSO 定义靠后同优先级按命令行出现顺序priority打破平局。所有自定义符号动作都是在这个关口插入的。--wrapsymbol语义是把symbol的引用重定向到__wrap_symbol原符号可通过__real_symbol访问文档见 docs/mold.md。源码里有三处介入解析命令行时link()把所有--wrap符号标记为WRAPPED位symbol.rs读取目标文件时input_files.rs遇到未定义引用若名字是__real_xxx且xxx在 wrap 列表里就把 key 还原成xxx若xxx本身在列表里就把 key 改写为__wrap_xxx。也就是说重定向发生在符号入表之前后续所有解析逻辑看到的都是改写后的名字LTO 时如前述wrap 符号要被强制标记为被常规对象引用防止被 LTO 内联掉。--defsymsymbolvalue定义一个符号别名。value 可以是整数定义绝对符号或另一个符号名。mold 的实现路径是合成一个内部对象文件create_internal_file()创建一个internal_obj把所有--defsym符号作为SHN_ABS全局符号塞进去passes.rs再在add_synthetic_symbols()里把别名关系落地——若目标是另一个符号就复制它的类型以及 PPC64v2 的 local entry 信息若目标是 DSO 符号则直接报错因为共享库定义的符号没有链接期地址不能被别名。这套内部合成对象机制还顺带承载了__ehdr_start、_end、_GLOBAL_OFFSET_TABLE_等一票链接器合成符号add_synthetic_symbols——它们和--defsym走的是同一条路作为 priority 为 0 的内部对象定义在 rank 竞争中天然胜过所有真实输入文件。可以理解为mold 把自定义符号实现成了伪造一个优先级最高的输入对象而不是在解析器里写一堆特判。生态现状与二次开发空间插件相关的能力散落在三块命令行入口-plugin/-plugin-optcmdline.rs其中-plugin-opt还接受-lto-*风格选项的别名解析、dlopen动态加载层、以及按文件类型识别 IR 对象的探测逻辑filetype.rs。值得一提的细节FAT LTO 对象GCC 编译的 FAT LTO 对象同时含常规 ELF section 和.gnu.lto_.symtabsection能在没有插件时退化为普通对象链接filetype.rsGCC offload 对象含.gnu.offload_lto_.*section 的对象通常携带 GPU 代码会在run_plugin()里单独喂给claim_file钩子让 LTO 后端处理异构代码lto.rs进程生命周期链接结束后若命令行指定了-pluginlink()会调用lto::cleanup()让插件清理临时文件driver.rsWindows 分支lto_win32.rs 中run_plugin是空实现——LTO 插件路径在 Windows 上暂不启用。对于想插一脚的开发者二次开发空间主要在两个方向一是复用dlopen transfer vector 这套回调基建实现自定义的符号改写/文件过滤逻辑-plugin接受任意.so只要实现onload即可二是直接嵌入--wrap/--defsym/--section-order这类伪合成对象机制利用internal_obj的零优先级定义特性实现比命令行选项更复杂的符号注入。需要清醒认识的是这套接口本质上是为 GCC/LLVM 的 LTO 后端服务的 C ABI全局状态、单线程钩子这些约束mold 为此专门维护了HOOKS/CLAIMED_SYMBOLS/CONTEXT三组全局变量意味着它并不适合当作通用插件框架来扩展mold 官方路线图上也始终把原生可扩展插件 API放在性能与兼容性之后。链接器是编译流水线的最后一道工序也是各种全局视角优化唯一能落地的位置。mold 的处理方式——C 回调协议 全局符号表竞争 合成对象注入——没有发明新概念却把三个最成熟的介入点做到了工程级严谨对插件不线程安全的现实妥协、对老 GCC API 的重启退路、对 wrap/defsym 与 LTO 叠加时的语义修补每一处都是踩过坑之后留下的痕迹。理解这些介入点你就能在需要动链接器的时候知道该往哪里伸手。【免费下载链接】moldmold : A Modern Linker in Rust 项目地址: https://gitcode.com/GitHub_Trending/mo/mold创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考