Сопоставление смещений в аварийном дампе iOS с дизассемблированным двоичным файлом

У меня возникли проблемы с сопоставлением смещений в трассировках стека аварийных дампов 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 не имеет смысла как фактическая рассматриваемая инструкция (включая тот факт, что, например, расположенные ниже по стеку, t указывают на инструкции ответвления).

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

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