У меня возникли проблемы с сопоставлением смещений в трассировке стека дампов аварийного восстановления iOS с смещениями при разборке двоичного файла в виде вывода otool.

Кто-нибудь может подтвердить, как в принципе я сопоставляю их. Например, если я получаю строку в аварийном дампе:

<code>0 myapp  0x00005b0a  0x1000 + 19210
</code>

я ожидал бы, что смещение ошибочной инструкции в двоичном файле будет 0x5b0a, 0x4b0a .... или что-то еще?

При декодировании информации заголовка otool также предоставляет, например, эту информацию (фактический код начинается со смещения 0x0000224c в файле):

<code>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
</code>

Итак, я не был на 100% уверен, что правильно интерпретировал это, но, похоже, он говорит, что код с размером + 0x224c в файле заканчивается смещением 0x124c в памяти, но тогда я точно не был уверен, как например, с местоположением 0x1000.

Проблема, с которой я столкнулся, заключается в том, что, учитывая, скажем, смещение 0x5b0a, ни инструкция там, ни в 0x4b0a, ни в 0x6b0a не имеет смысла как фактическая рассматриваемая инструкция (включая тот факт, что, например, места, расположенные ниже по стеку, не указывают на ветка инструкции).

(Я знаю, что, по крайней мере в более ранних воплощениях ARM, было несоответствие между значением ПК и соответствующим адресом памяти из-за конвейера инструкций. Я былassuming что такое различие будет учтено в смещениях, о которых сообщается в дампе аварии, или, во всяком случае, я вижу в инструкции по ветвлению несколько инструкций по обе стороны от того, на который указывалось, если такое различие не было принято в учетную запись...)

Кто-нибудь может пролить свет?