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

Question

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

找到一些可靠的信息很难,但我猜测dyld_stub_binder实际上执行了动态系统库的后期链接.

我倾向于遇到崩溃,异常是EXC_BREAKPOINT UNKNOWN,崩溃似乎总是发生在dyld_stub_binder的上下文中.

dyld_stub_binder的实现在苹果开源网站上.我不太了解程序集,但也许有人可以解释为什么会发生这种错误,或者它是否是应用程序直接控制之外的东西.汇编代码可能没有用,因为我在谈论iOS(arm)实现,这段代码是i386和x86_64.

编辑:一个有趣的信息是,我认为我在开始移植到arm64的过程中开始看到这次崩溃.像这样的运行时异常是否可能是由于某种错位造成的？

Answer 1

正如您所说，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    

看到那里的 printf 了吗？0x100007f84？让我们看看那是什么（内置的 otool 不能反编译那部分，但 jtool 可以：）

_printf:
   100007f84    NOP                     
   100007f88    LDR    X16, #34         ; R16 = *(100008010) = 0x100007fa8

   100007f8c    BR     X16   

所以你只需要 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_bind 来验证：

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

这意味着，在第一次访问时，stub_binder 在 lib 系统中找到 printf 的地址，并将其嵌入那里。

如果无法绑定符号，则会出现异常。虽然这可能是出于很多原因。您可能想在此处添加崩溃日志。如果是断点，则是 dyld 的自愿崩溃，通常在未找到符号时发生。如果附加了调试器 (lldb)，它将在那里中断。否则 - 没有调试器 - 它会崩溃。