第一次在otool -l输出里看到__TEXT,__stubs_helper的时候我盯着它愣了很久。__text放业务代码__stubs放整齐的跳板__la_symbol_ptr负责存函数地址这些按名字都能猜个大概。但一个名字里带 helper 的节到底是给谁帮忙的后来在查一个启动性能相关的问题时我才意识到所有懒加载符号的第一次调用都会故意走进这节代码而这个节的执行结果又会在眨眼之间跳进dyld_stub_binder。可以说不理解__stubs_helper就没办法真正读懂 iOS/macOS 程序里的懒加载机制。这篇是 Mach-O 系列的延展篇我按照自己在真机、模拟器和命令行工具里反复验证过的路径把这一节的背景、结构、执行流程和现代链接器对它带来的变化完整拆一遍。适合系统程序员、二进制分析爱好者和对 dyld 内部机制好奇的开发者。1. 没有 __stubs_helper懒加载符号会在哪里断掉1.1 懒加载到底在偷什么懒一个 Mach-O 程序里调用了printf编译期链接器并不会真的把 printf 的实现复制进来也不会在生成可执行文件时就查好 printf 的最终地址。它只会在__la_symbol_ptr里留一个槽位在调用点生成一小段跳板代码然后承诺等程序跑起来、第一次真的执行到这一行时再把 printf 的真实地址填进槽位。这就是懒加载。这样做的直接好处是启动快。程序加载时不需要解析所有外部符号尤其是那些可能只在某个冷门分支里用到的函数。dyld 在启动阶段只需要处理少量非懒绑定符号其余全部留到调用时再说。对大型 App 来说这个偷懒能省下不少启动时间。但反过来想懒加载到底需要谁来完成第一次填充dyld 里有一个核心函数dyld_stub_binder它负责查找符号、绑定地址、写回槽位。调用点不可能直接把控制权交给dyld_stub_binder因为 binder 需要知道现在要绑定的到底是哪个符号。这个信息必须通过某种方式传给它。如果直接跳过去binder 拿到的是一个返回地址它确实能通过返回地址推断调用位置但还需要一块专门的代码来保证现场安全、帮它做最后的跳转准备。这块专门的代码就是__stubs_helper。1.2 三件套的准确分工在通常的 Mach-O 里懒加载依赖三个 section 配合工作我把它们对比如下Section职责典型形态__TEXT,__stubs每个外部懒加载符号对应一小段跳板代码调用方bl到这里arm64 下通常是adrp; ldr x16; br x16三连__DATA,__la_symbol_ptr存放每个懒加载符号的指针槽位绑定前指向 helper绑定后指向真实函数8 字节一个指针__TEXT,__stubs_helper未绑定前的辅助代码负责跳转到 dyld_stub_binder一小段一小段的汇编片段调用方不会直接调用__la_symbol_ptr里的函数而是先跳到__stubs。__stubs从一个具体的 slot 里读出当前值然后执行它。如果这个符号还没被绑定slot 里的值就是__stubs_helper中某个 helper 片段的地址。于是执行流来到了 helper。如果符号已经绑定了slot 里就是真实函数地址执行流直接进真实函数。这也是很多人第一次看反汇编时容易绕晕的地方__stubs的代码看起来每次都一样但能不能直接执行完全取决于 slot 里的值。而这个 slot 的初始值就是由链接器写进__stubs_helper地址的。1.3 一个反直觉的事实helper 不是用来完成绑定的我刚接触时有个误解以为__stubs_helper里应该有符号解析逻辑、字符串比较之类的东西。看完反汇编就明白了它一共就五六条指令做的事情非常单纯保护现场、定位 dyld_stub_binder 地址、跳过去。真正完成绑定的是 dyld 内部代码。helper 只是把执行流交接给 binder 的那只手。如果把整个懒加载机制比作一个快递柜__stubs是取件入口__la_symbol_ptr是柜子里的格子helper 则是贴在格子上的未投放标签。取件时看到未投放标签不会帮你把快递找出来它只会告诉快递员这个格子需要处理了。快递员才是 binder。理解了这一层再去看 helper 的汇编就不会觉得它内容太少。它本来就应该少少到不影响正常调用路径少到每个符号都可以共用同一套逻辑。2. 定位 __stubs_helpersection 头、地址和大小2.1 从 section header 里能读到什么Mach-O 的 section header 描述了这个 section 在文件里的位置、内存里的虚拟地址、对齐方式和属性。执行下面的命令可以在任意一个 Mach-O 二进制里看到它的节信息otool -l MyTestApp | grep -A 8 -E sectname __stubs_helper我用自己的测试程序跑这段输出大概是Section sectname __stubs_helper segname __TEXT addr 0x0000000100008b00 size 0x0000000000000060 offset 0x8b00 align 4 reloff 0 nreloc 0 flags 0x80000400 reserved1 0 reserved2 0这里align 4表示 2^4 16 字节对齐。为什么是 16 字节因为 helper 是纯代码片段arm64 下每条指令 4 字节常见的 helper 形态是 12 字节占 3 条指令但链接器为了对齐到 16 字节边界会在这个 section 内部做填充。size 0x60是 96 字节可能包含 6 个 helper 片段和少量填充。flags字段值得注意。0x80000400等于S_ATTR_PURE_INSTRUCTIONS与S_ATTR_SOME_INSTRUCTIONS的组合表示这个 section 只包含指令没有数据混在里面。这跟__text是一样的属性。所以不要把它当成普通的只读常量区它是一段可执行代码。2.2 用命令行工具确认反汇编范围拿到起始地址和大小之后可以立刻反汇编这段区域otool -v -s __TEXT __stubs_helper MyTestApp这个命令专门反汇编__TEXT,__stubs_helper输出会比otool -t更聚焦适合快速目测。如果想用 LLVM 系的工具也可以这样llvm-objdump --macho --disassemble --section__TEXT,__stubs_helper MyTestApp我一般两个都跑一遍原因是otool对 dyld 私有符号的显示更接近系统风格llvm-objdump在指令字节和助记符的排版上更清晰。两个工具相互对照能很快确认每个 helper 片段的边界。2.3 别忘了地址的三层关系section header 里的offset是文件偏移addr是未加 slide 的虚拟地址。程序运行时由于 ASLR整个__TEXT段会被加载到一个随机基址上。也就是说调试器里看到的 helper 实际地址是实际地址 vmaddr slideslide可以通过 lldb 的image list -o查看。很多人第一次在调试器里照着addr下断点结果断不下来就是因为忘了加 slide。理解了这一层后面调试就不会白忙。3. 逐指令还原 helper 汇编每条指令都有明确任务3.1 arm64 真机上最常见的 helper 形态在真机 arm64 架构上一个典型的 helper 片段长这样stp x16, x17, [sp, #-16]! adrp x16, _dyld_stub_binderPAGE ldr x17, [x16, _dyld_stub_binderPAGEOFF] add x16, x16, _dyld_stub_binderPAGEOFF br x17逐条看第一条stp x16, x17, [sp, #-16]!。这条指令做了两件事把栈指针往下移 16 字节同时把 x16 和 x17 这两个寄存器压栈。ARM64 调用约定里x16 和 x17 是调用者保存的临时寄存器helper 本身要借用它们来算地址但跳到 binder 后 binder 也有权随意改这两个寄存器所以在跳之前先把它们存起来。栈指针减 16 后依然保持 16 字节对齐这也是调用 binder 之前应该满足的栈对齐条件。第二条adrp x16, _dyld_stub_binderPAGE。adrp以当前指令所在页为基准通过 PC 相对偏移拿到 dyld_stub_binder 所在页的基地址放进 x16。因为 Mach-O 里 dyld_stub_binder 的地址在运行时才确定链接器只能用重定位让这个指令在加载时被改写PAGE就是这种 PC 相对页地址的写法。第三条ldr x17, [x16, _dyld_stub_binderPAGEOFF]。从 x16 指向的页内偏移处读出真正的 dyld_stub_binder 指针放到 x17。这里读的是一个指针值这个指针通常放在__got或者 dyld 的某个私有数据区里binder 的实际地址靠这次访存取出来。第四条add x16, x16, _dyld_stub_binderPAGEOFF。把页基地址加上页内偏移。这一步看起来有点多余但如果碰巧 dyld_stub_binder 地址位于页内某个偏移它主要还是为了保证 x16 里有一个完整地址方便后续调试或者某些版本的 binder 通过寄存器拿到必要信息。第五条br x17。直接跳转到 x17 里保存的 binder 地址。注意这里用的是br而不是blr。如果是blr会先把返回地址写进 LR那 binder 返回时会跳回这个 helper逻辑就乱了。这里br不会修改 LRLR 仍然是调用者跳进__stubs之前由bl写入的下一条指令地址。dyld_stub_binder 正是靠这个 LR 知道调用点在哪进而知道该绑定哪个符号。3.2 x86_64 平台的 helper 长什么样x86_64 上因为指令密度更高、寻址方式更丰富helper 往往更短。旧版本常见的是jmpq *0x00000000(%rip)后面紧跟一个重定位加载时被改成 dyld_stub_binder 在 GOT 中的地址。也有用callq的变体但语义都一样把控制权交给 binder。由于 x86_64 的调用约定里返回地址会自然压栈binder 同样能通过栈上内容定位调用方。我在做跨架构对比时最深的感受是架构变了helper 的实现细节变了但它的使命没变。它的存在不是为了完成某件具体的事而是为了让编译器、链接器和 dyld 之间有一个稳定的交接协议。3.3 怎么识别 helper 片段的边界如果反汇编完__stubs_helper你会看到内容不是一整段连续函数而是由好几个 12 到 20 字节的小片段组成。每个片段之间可能隔着0x4的填充字节。识别方法很简单每个片段几乎都是从stp x16, x17或者sub sp开头并且最终都以br结尾。一个符号还没绑定它的__la_symbol_ptrslot 就指向其中一个片段。链接器会为每个懒加载符号准备片段也可能让多个符号共享同一个片段这取决于链接器的优化策略。当 dyld 需要确定哪个 symbol 触发了绑定时它通过 LR 找到__stubs里的跳板代码再根据跳板到__la_symbol_ptr的偏移关系定位具体 slot。所以 helper 片段本身根本不需要把符号名printf之类的字符串写在身边这也是它体积能这么小的原因。4. helper 与 dyld_stub_binder 的握手协议4.1 第一次调用现场假设你的 C 代码里有一句printf(hello\n)。编译链接后调用点通常会变成bl _printfstubs这条bl会把返回地址写进 LR然后跳进__TEXT,__stubs里对应 printf 的跳板。__stubs中的跳板代码大致是adrp x16, _la_symbol_ptrPAGE ldr x16, [x16, _la_symbol_ptrPAGEOFF] br x16这里ldr从 printf 对应的 slot 里取出现在存放的指针。如果是第一次调用这个指针就是__stubs_helper中某个 helper 片段的地址。于是br x16把控制权交给了 helper。整个过程里LR 一直停留在调用点bl _printfstubs的下一条指令地址。这个细节非常关键binder 之后要回去就是靠这个 LR。4.2 helper 到 binder 之间发生了什么接着执行 helper。前面讲的五条指令跑完CPU 跳到 dyld_stub_binder。此时寄存器状态是LR 保存的是调用 printf 的那个bl的下一条指令地址x16/x17 已经被压栈helper 里剩下的是计算好的完整地址或者页信息参数寄存器 x0 到 x7 仍然是调用 printf 时的原样。为什么参数寄存器要保持原样因为 dyld_stub_binder 绑定完成后最终要假装什么都没有发生过让程序继续像调用 printf 一样执行。binder 拿到这些参数才能在绑定完成后原封不动地返回调用点让真正的 printf 接着使用 x0 等参数。4.3 dyld_stub_binder 的工作内容dyld_stub_binder 会从 LR 反推调用位置。它找到__stubs中的跳板地址再根据跳板地址确定对应的__la_symbol_ptrslot然后去 dyld 的符号表里查找这个 symbol 的真实地址。找到后它会把真实地址写回 slot最后跳回 LR。这一步结束后printf 的 slot 值就发生了如下变化时机slot 内容执行效果第一次调用前__stubs_helperhelper 片段地址执行 helper再进 binder 绑定第一次绑定后、第二次调用前printf 真实函数地址直接跳进 printf 实现绑定进行中尚未写回同一线程不会出现并发dyld 内部有锁保护写回 slot 的动作在汇编层面就是一个str但对整个进程来说它改变了后续所有调用的路径。4.4 第二次调用省掉了什么第二次调用printf执行流是调用点 bl 到 __stubs - __stubs 里 ldr 到 slot - slot 已经是 printf - br 进 printf这次不再经过 helper也不再经过 dyld_stub_binder。省掉的不只是一个函数跳转而是动态查询符号表、解析依赖、写回指针这一整串操作。对于频繁调用的热门函数这个差异在性能剖析里非常明显。这也是为什么-no_lazy_binding链接选项会导致启动变慢但运行时变快所有符号都在启动阶段绑定完成调用路径上永远不需要走 helper。但代价是启动时要做更多符号解析。理解 helper 之后你会对这类优化选项的取舍有更具体的感知。5. 用调试器和命令行工具观察 helper 的实战记录5.1 在 lldb 里精准断到 helper先看 slide(lldb) image list -o输出里会有一行类似0x000000010abc0000的偏移这就是当前镜像的 slide。然后我能通过 section 地址算出运行时 helper 地址。不过更省事的方法是直接在dyld_stub_binder上断点(lldb) breakpoint set -n dyld_stub_binder运行程序后只要第一次调用任何一个懒加载符号都会停在这里。此时看 LR(lldb) register read lr再结合反汇编__stubs_helper就能很直观地看到调用点来自哪一段 helper 代码。如果确实想停在 helper 代码本身可以(lldb) breakpoint set -a 0x0000000100008b00注意 0x100008b00 是 section header 里的静态地址在调试前要先加上 slide。严格来说应该先确认当前进程的基址。我实测时发现把断点下在 helper 里用step over走指令很容易一头扎进完全陌生的 dyld 内部代码。原因很简单helper 用br x17跳走普通单步逻辑会把这一步当作一个普通跳转。想观察绑定完成后回到调用点的过程更好的做法是直接对dyld_stub_binder下断点然后在 binder 返回前查看寄存器。5.2 对照 otool 和 llvm-objdump 的输出我习惯用两段命令同时验证otool -v -s __TEXT __stubs_helper MyTestApp输出示例MyTestApp: (__TEXT,__stubs_helper) section _dyld_stub_binder: 0000000100008b00 stp x16, x17, [sp, #-0x10]! 0000000100008b04 adrp x16, 0x10000c000 0000000100008b08 ldr x17, [x16, #0x10] 0000000100008b0c add x16, x16, #0x10 0000000100008b10 br x17 0000000100008b14 brk #0x1后面那个brk #0x1一般是对齐填充或者「不可达」标记不代表真实逻辑。再用llvm-objdump --macho --disassemble --section__TEXT,__stubs_helper MyTestApp能把每一条指令的字节码都打出来方便你检查文件的原始字节。两个命令输出的指令语义应当一致只是otool偶尔会把 helper 片段统一标成_dyld_stub_binder看起来像只有一个符号其实可能是多个片段要注意看地址差异。5.3 崩溃日志里出现 helper 地址怎么办当程序在第一次调用某个懒加载符号时崩溃崩溃栈里可能会显示一个位于__stubs_helper范围内的地址而不是一个明明白白的函数名。因为 helper 本身没有符号符号化工具只能给出__TEXT,__stubs_helper offset这种格式。拿到这类地址后不要慌。先用atos按二进制的 load address 和崩溃地址换算atos -o MyTestApp -l 0x100000000 0x100008b04大多数情况下atos会输出dyld_stub_binder或者类似名字。如果输出依然是 helper就说明崩溃不是发生在某个业务函数里而是在懒加载绑定的边缘。常见原因是二进制依赖的某个符号在链接后发生了变化或者调用发生在 dyld 初始化完成之前。这类问题的排查难点往往不在 helper 本身而在于为什么第一次调用会走到这里。理解了 helper你就不会把崩溃原因误判为普通代码缺陷而是会去检查符号表、依赖库版本和链接选项。5.4 两个特别容易忽略的细节第一helper 不是 C 函数没有调试信息没有符号表条目也不符合普通函数 prologue/epilogue 的规律。所以任何基于栈帧的函数回溯工具在面对 helper 时都可能给出不精确的结果。分析时要学会接受地址正确但名字缺失的状态。第二同一份二进制在不同 iOS 系统版本上helper 的具体汇编可能不同。系统库里的 helper 由系统链接器生成App 里的 helper 由 App 的链接器生成它们的实现可能基于同一套规范但指令选择会有差异。不要拿一份二进制上的指令形态硬套到另一份上。6. chained fixups 之后__stubs_helper 还有没有存在感6.1 chained fixups 改变了什么从 macOS 11/iOS 14 开始Apple 新的 dyld 运行环境默认使用 chained fixups。这是一种把重定位信息打包进数据指针自身的方案每个待修复的指针不再依赖独立的__la_symbol_ptr表和外部重定位记录。指针的低位里编码着 ordinal、addend 和绑定类型dyld 在加载时通过扫描这一串链式指针就能一次性完成修复。这个方案大幅度降低了启动阶段的内存访问量和 page fault也让 dyld 不再需要保留旧的__stubs_helper专门用于懒加载跳转。新的可执行文件里__stubs_helper常常是空的甚至整个 section 都不存在。但这不代表旧格式消失了。系统里仍充斥着大量旧版本编译出的 App、动态库和系统框架这些二进制里依然有完整的__stubs/__la_symbol_ptr/__stubs_helper三件套。而且即使是 chained fixups 时代某些被标记为lazy的符号仍然需要一种未绑定时的去向只是去向从 helper 变成了一种更紧凑的指针编码。6.2 老三件套和新默认格式的共存我用 Xcode 14 之后默认参数编了一个测试程序查看 sections发现__stubs_helper的 size 经常是 0。再改用旧版链接参数或者从老设备上取一个 App又能看到熟悉的 96 字节。这说明 helper 的有无主要取决于链接时是否启用了新式链式修复。可以简单对照链接方式__la_symbol_ptr__stubs_helper首次调用路径旧式 lazy bind存在slot 初始指向 helper存在stub - slot - helper - binder新式 chained fixups存在但使用链式指针编码通常为空或缺失stub - slot - 直接解析后的目标关闭 lazy binding存在但启动时已填好没有stub - slot - 目标从这个表能看出helper 本质上是一个和特定链接策略绑定的产物。它不是 Mach-O 格式里永恒存在的标准件而是链接器为了推迟决定而设计出来的一个中间层。6.3 理解 helper 对阅读新老二进制的价值即使现在新链接器很少再生成大量 helper理解它仍然有实际价值。第一很多系统库和第三方依赖依然以旧方式链接崩溃栈里也会闪现 helper 地址。第二新式 chained fixups 的设计目标就是解决旧式 lazy binding 带来的开销不理解旧式机制就无法评价新机制的收益。第三手动分析老设备上的二进制、做兼容性支持时helper 几乎是必经之路。所以我的建议是不必把__stubs_helper当作一个需要背诵的固定结构而应该把它看成动态绑定机制在懒加载场景下的一个设计样本。理解了它再看 dyld 的源码、再看链接器的重定位处理、再看启动优化的各种手段都会有很强的贯通感。我在实际分析一个线上问题时就遇到过这种情况崩溃日志里反复出现某个 helper 偏移最初怎么都想不通。后来把地址换算到__la_symbol_ptr的对应 slot才发现是后台下发的配置里声明了一个旧版本里不存在的符号导致首次调用时 dyld 找不到实现。那次之后我养成了一个习惯先确认崩溃地址落在哪个 section再判断这是不是一次懒加载边界问题而不是直接去读函数代码。这个习惯帮我省了很多无用功也希望这篇文章能帮你少走同样的弯路。
