15

我无法将 iOS 崩溃转储的堆栈跟踪中的偏移量与 otool 输出的二进制反汇编中的偏移量相匹配。

任何人都可以确认我原则上是如何匹配这些的。例如，如果我在故障转储中得到一行：

0 myapp  0x00005b0a  0x1000 + 19210

我是否希望二进制文件中违规指令的偏移量为 0x5b0a、0x4b0a.... 或其他？

在对头信息的解码中，otool 还给出了例如该信息（实际代码从文件中的偏移量 0x0000224c 开始）：

Section
  sectname __text
   segname __TEXT
      addr 0x0000224c
      size 0x00063ad2
    offset 4684
     align 2^2 (4)
    reloff 0
    nreloc 0
      type S_REGULAR
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS
 reserved1 0
 reserved2 0

所以，我不是 100% 确定我是否正确解释了这一点，但似乎是在说文件中 +0x224c 处的代码在内存中的偏移量 0x124c 处结束，但后来我不确定这是怎么回事例如，安装位置 0x1000。

我遇到的问题是，假设偏移量为 0x5b0a，那里的指令、0x4b0a 或 0x6b0a 的指令都没有作为有问题的实际指令有意义（包括这样一个事实，即堆栈更下方的位置然后不指向分支指令）。

（我知道，至少在 ARM 的早期版本中，由于指令流水线，PC 的值与相应的内存地址之间存在差异。我假设在报告的偏移量中会考虑这种差异在故障转储中，或者无论如何，如果没有考虑到这种差异，我会看到有问题的分支指令，它的任一侧都指向了一些指令......）

任何人都可以解释一下吗？

4

2 回答 2

7

将段的虚拟地址添加__TEXT到故障转储中给出的相对地址。结果是要在反汇编中查找的地址。以下是步骤：

  1. 用于otool -lv <application-binary>从应用程序二进制文件中转储加载命令。查找段的加载命令__TEXT 以及 的相关值vmaddr，通常是0x1000。您不需要有关上面显示的__text 部分的信息，只需要有关段的信息。

  2. 在故障转储中，调用堆栈中的地址以 0x00124ff4 0xf4000 + 200692. 最后一部分是十进制二进制中的偏移量。将此添加到步骤 1 中获得的值并转换为十六进制。在这个例子中，我们将计算0x1000 + 200692哪个是0x31ff4十六进制的。

  3. 用于otool -tV <application-binary>转储应用程序二进制文件的反汇编。找到在步骤 2 中获得的地址（0x31ff4在此示例中）。对于调用堆栈的最顶层帧，这是应用程序崩溃的地方。对于所有其他级别，在计算的地址处应该是对应于堆栈中下一个更高级别的分支指令。

于 2013-09-30T20:11:39.123 回答
2

前提是myapp没有去掉你可以使用的符号atos。

您可以随时man atos了解更多详细信息，但这应该足以解决您的问题：

-o symbol_file # debugging information output by the compiler this may be a dSYM or the binary itself depending on who you saved symbol information
-l load address # the base address in the process space at which your library is loaded into the springboard process (Looks like 0x1000)
Also a list of addresses you wish to symbolicate

Usage:
    atos -o myapp -l 0x1000 0x00005b0a 0x0005bca ... etc

该输出应该是终端的符号名称列表。同样，这要求myapp没有删除符号。

于 2012-05-26T21:41:26.120 回答