匹配iOS崩溃转储中的偏移到反汇编的二进制文件 [英] Matching up offsets in iOS crash dump to disassembled binary

问题描述

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

I'm having trouble matching up the offsets in the stack traces of iOS crash dumps with offsets in the disassembly of the binary as output by otool.

任何人都可以确认我原则上如何匹配这些。例如，如果我在崩溃转储中获得一行：

Can anybody confirm how in principle I match these up. For example, if I get a line in the crash dump:

0 myapp  0x00005b0a  0x1000 + 19210

我希望二进制文件中违规指令的偏移量为0x5b0a，0x4b0a ....还是其他什么？

would I expect the offset of the offending instruction in the binary file to be 0x5b0a, 0x4b0a.... or something else?

在解码头信息时，otool还提供了这样的信息（实际代码从文件中的偏移量0x0000224c开始）：

In its decoding of the header information, otool also gives, for example, this information (the actual code starts at offset 0x0000224c in the file):

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。

So, I wasn't 100% sure I was interpreting this correctly, but it seems to be saying that the code, at +0x224c in the file, ends up at offset 0x124c in memory, but then I wasn't exactly sure how this fitted in with, for example, the location 0x1000.

我遇到的问题是给出了偏移量0x5b0a，既不是指令也不是0x4b0a，也不是0x6b0a作为有问题的实际指令是有道理的（包括例如位于堆栈下方的位置然后不指向分支指令。）

The problem I have is that given, say, the offset 0x5b0a, neither the instruction there nor at 0x4b0a nor at 0x6b0a makes sense as being the actual instruction in question (including that fact that e.g. locations further down the stack then don't point to branch instructions).

（我知道，至少在ARM的早期版本中，值之间存在差异由于指令管道而导致的PC和相应的内存地址。我假设在崩溃转储中报告的偏移量中会考虑这种差异，或者无论如何，我会如果没有考虑到这样的差异，请查看有问题的分支指令，指示一边指示......）

(I know that, at least on earlier incarnations of ARM, there was a discrepancy between the value of the PC and the corresponding memory address due to the instruction pipeline. I was assuming that such a difference would be taken into account in the offsets reported in the crash dump, or at any rate, I'd see the branch instruction in question a few instructions either side of the one pointed to if such a difference wasn't taken into account...)

任何人都可以解决问题？

Can anybody shed any light?

推荐答案

如果 myapp 没有删除符号你会能够使用 atos 。

Provided that myapp did not strip out symbols you'll be able to use atos.

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

You can always man atos for more details but this should be sufficient for your problem:

-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 没有删除符号。

That output should be a list of symbol names to the terminal. Again, this requires that the myapp did not have symbols stripped out.

这篇关于匹配iOS崩溃转储中的偏移到反汇编的二进制文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！