为什么会发生与dyld_stub_binder相关的iOS崩溃？

众所周知，iOS应用程序中不允许使用动态链接库，它们只能链接到动态系统库。但我确实遇到了一些相当混乱的崩溃，堆栈顶部的第三帧是dyld_stub_binder

很难找到可靠的信息，但我猜dyld_stub_binder实际上执行动态系统库的后期链接

我倾向于遇到异常为EXC_断点未知的崩溃，崩溃似乎总是发生在dyld_stub_binder的上下文中

的实现在苹果开源网站上。我不太了解程序集，但也许有人可以解释为什么会发生这个错误，或者它是否超出了应用程序的直接控制。不过，汇编代码可能没有什么用处，因为我正在谈论iOS（arm）实现，而这段代码是i386和x86_64

---

编辑：一条有趣的信息是，我想我在移植到arm64的过程中开始看到这个崩溃。像这样的运行时异常是否可能是由于某种未对齐造成的？

如您所述，ARM案例的asm不可用，但由于您可以相当轻松地进行反编译，因此很容易确定。dyld_stub_binder（在所有体系结构上）所做的是在二进制文件中处理惰性符号。例如，考虑以下内容：

   $ cat a.c
void main(int argc, char **argv)
{

    printf("%s", argv[1]);

}
$ gcc-iphone a.c -o a 
$ jtool -d a
Disassembling from file offset 0x7f44, Address 0x100007f44 
_main:
   100007f44    STP    X29, X30, [X31,#-16]!    
   100007f48    ADD    x29, x31, #0x0   ; ..R29 = R31 (0x0) + 0x0 = 0x1f 
   100007f4c    SUB    X31, X31, #32    
   100007f50    STUR   X0, X29, #-4     ; *((1) + 0x0) = ???
   100007f54    STR    X1, [ X31, #2]   ; *((2) + 0x0) = ???
   100007f58    LDR    X1, [X31, #0x10] ; R1 = *(10) = 0x100000cfeedfacf
   100007f5c    LDR    X1, [X1, #0x8]   ; R1 = *(100000cfeedfad7) = 0x100000cfeedfacf
   100007f60    ADD    x8, x31, #0x0    ; ..R8 = R31 (0x0) + 0x0 = 0x1f 
   100007f64    STR    X1, [ X8, #0]    ; *(0x0) = 0xfeedfacf
   100007f68    ADRP   x0, 0            ; ->R0 = 0x100007000 
   100007f6c    ADD    x0, x0, #0xfb4   ; ..R0 = R0 (0x100007000) + 0xfb4 = 0x100007fb4 "%s"
   100007f70    BL     _printf  ; 0x100007f84
; _printf("%s",arg..);

   100007f74    STR    X0, [ X31, #3]   ; *((254) + 0x0) = ???
   100007f78    ADD    x31, x29, #0x0   ; ..R31 = R29 (0x1f) + 0x0 = 0x1d 
   100007f7c    LDP    X29, X30, [X31],#16  
   100007f80    RET    

看到上面那张照片了吗？0x100007f84？让我们看看这是什么（内置的otool无法反编译该部分，但jtool可以：）

所以您只需将其设置为0x100007fa8。再次应用jtool：

$ jtool -d 0x100007fa8 a
Disassembling from file offset 0x7fa8, Address 0x100007fa8 
   100007fa8    LDR    X16, #2          
   100007fac    B      0x100007f90

现在我们有0x100007f90，这是

   100007f90    ADR    x17, 120         ; ->R17 = 0x100008008 
   100007f94    NOP                     
   100007f98    STP    X16, X17, [X31,#-16]!    
   100007f9c    NOP                     
   100007fa0    LDR    X16, #24         ; R16 = *(100008000) dyld_stub_binder
   100007fa4    BR     X16              

现在，回到加载的0x…8010，这将是printf（）的地址，但它仅在第一次“命中”或访问之后绑定。您可以使用dyldinfo或jtool-lazy\u-bind验证：

$ jtool -lazy_bind a
bind information:
segment section          address        type    addend dylib            symbol
__DATA  __la_symbol_ptr  0x100008010    ...     0 libSystem.B.dylib    _printf

也就是说，在第一次访问时，存根绑定器在lib系统中找到printf的地址，并将其嵌入其中

---

如果无法绑定符号，则会出现异常。虽然有很多原因。您可能需要在此处添加崩溃日志。若它是一个断点，那个么这是dyld自愿性的崩溃，通常在找不到符号时发生。如果附加了调试器（lldb），它将在那里中断，然后重试。否则-没有调试器-它会崩溃。

是的，我知道它是系统库的后期绑定，我应该更清楚。但是，关于为什么通常会在美国发生撞车，人们感到困惑。例如，我们在项目中将vorbis构建为一个单独的库，并且在mdct_init中偶尔会看到崩溃。它所做的只是分配缓冲区和使用libmath（idct的余弦表，作为iOS系统动态库提供）中的trig函数。这些函数都在math.h中声明为外部函数，例如在运行时绑定而不使用静态库。如果libmath.dylib由于某种原因未加载或无法由iOS加载，这可能是一个问题。顺便说一句，答案很好。由于字符限制，我不得不在欣赏字符串中删掉一些字符。

$ jtool -lazy_bind a
bind information:
segment section          address        type    addend dylib            symbol
__DATA  __la_symbol_ptr  0x100008010    ...     0 libSystem.B.dylib    _printf