dSYM 地址查找

Question

我已经从一个 iOS 应用程序的 dSYM 文件中解析出地址、文件名和行号。我基本上有一个将地址映射到文件名和行号的表，这对调试很有帮助。

要获取actual lookup address，我使用崩溃报告中的堆栈跟踪地址并使用此答案中指定的公式：https://stackoverflow.com/a/13576028/2758234。所以像这样。

(actual lookup address) 
= (stack trace address) + (virtual memory slide) - (image load address)

我使用该地址并在我的桌子上查找它。我得到的文件名是正确的，但是行号总是指向被调用的函数或方法的末尾，而不是在堆栈跟踪中调用以下函数的实际行。

我在某处读过，不记得在哪里，必须取消标记帧地址，因为它们对齐以使系统指针大小加倍。所以对于 32 位系统，指针大小是 4 字节，所以我们使用 8 字节去标记，使用如下公式：

(de-tagged address) = (tagged address) & ~(sizeof(uintptr_t)*2 - 1)

其中uintptr_t 是Objective-C 中用于指针的数据类型。

完成此操作后，查找排序工作，但我必须执行类似找到小于或等于去标记地址的最近地址之类的操作.

问题 #1：
为什么我必须取消标记堆栈帧地址？为什么堆栈跟踪中的地址没有指向正确的位置？

问题 #2：
有时在崩溃报告中似乎缺少帧。例如，如果function1() 调用function2() 调用function3() 调用function4()，在我的堆栈跟踪中我会看到类似的内容：

0  Exception
1  function4()
2  function3()
4  function1()

function3()（上面的第 2 帧）的堆栈跟踪地址甚至没有指向正确的行号（但它是正确的文件），即使在取消标记之后也是如此。即使我让 Xcode 表示崩溃报告，我也会看到这一点。

为什么会这样？

Answer 1

对于问题 #1，iOS 崩溃报告中的地址包含三个需要考虑的组成部分：应用的原始加载地址、应用启动时添加到该地址的随机滑动值以及二进制内的偏移量。在崩溃报告的最后，应该有一行显示二进制文件的实际加载地址。

要计算幻灯片，您需要从崩溃报告中获取实际加载地址并减去原始加载地址。这会告诉您应用到此特定应用启动的随机幻灯片值。

我不确定您是如何得出表格的 - 问题可能出在那儿。您可能需要使用 lldb 进行仔细检查。您可以将您的应用加载到 lldb 并告诉 lldb 它应该加载到地址 0x140000（这将是您的崩溃报告中的实际加载地址，不要担心幻灯片和原始加载地址）

% xcrun lldb
(lldb) target create -d -a armv7 /path/to/myapp.app
(lldb) target modules load -f myapp __TEXT 0x140000

现在 lldb 已将您的二进制文件加载到此崩溃报告的实际加载地址。您可以在 lldb 中执行所有常用查询，例如

(lldb) image lookup -v -a 0x144100

对地址 0x144100（可能出现在您的崩溃报告中）进行详细查找。

您还可以使用target modules dump line-table 在 lldb 中执行漂亮的“转储您的内部行表”命令。例如，我编译了一个 hello-world Mac 应用程序：

(lldb) tar mod dump line-table a.c
Line table for /tmp/a.c in `a.out
0x0000000100000f20: /tmp/a.c:3
0x0000000100000f2f: /tmp/a.c:4:5
0x0000000100000f39: /tmp/a.c:5:1
0x0000000100000f44: /tmp/a.c:5:1
(lldb) 

我可以更改我的二进制文件的加载地址并再次尝试转储行表：

(lldb) tar mod load -f a.out __TEXT 0x200000000
section '__TEXT' loaded at 0x200000000
(lldb) tar mod dump line-table a.c
Line table for /tmp/a.c in `a.out
0x0000000200000f20: /tmp/a.c:3
0x0000000200000f2f: /tmp/a.c:4:5
0x0000000200000f39: /tmp/a.c:5:1
0x0000000200000f44: /tmp/a.c:5:1    
(lldb) 

我不确定我是否理解您对地址的去标签所做的事情。调用堆栈上的地址是这些函数的 return 地址，而不是 call 指令 - 所以这些可能指向实际方法调用/调度源行之后的行，但是当您查看源代码时，这通常很容易理解。如果您所有的查找都指向方法的结尾，我认为您的查找方案可能有问题。

至于问题 #2，如果帧 #0（当前正在执行的帧）是未设置堆栈帧的叶函数，或者位于建立堆栈帧的过程。在这些情况下，可以跳过第 1 帧。但是，一旦您超过了第 1 帧，尤其是在手臂上，展开不应错过任何帧。

当一个标记为noreturn 的函数调用另一个函数时，有一个非常边缘的皱纹，该函数的最后一条指令可能是一个调用——没有函数结尾——因为它知道它永远不会再获得控制权。很不常见。但是在这种情况下，一个简单的符号会给你一个指向内存中下一个函数的第一条指令的指针。调试器等人在进行符号/源代码行查找时使用了一种技巧，即从返回地址中减去 1 来回避这个问题，但这并不是临时符号化者通常需要担心的事情。并且您必须小心不要对当前执行的函数（第 0 帧）执行 decr-pc 技巧，因为函数可能刚刚开始执行，并且您不想将 pc 备份到前一个函数中并错误地符号化.