Вопрос по ios – Соответствие смещений в аварийном дампе iOS для разобранного двоичного файла

14

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

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

Есть ли причина, по которой вы не можете просто символизировать?stackoverflow.com/questions/3832900/… Alex Taylor
Я не могуsimply символизировать, потому что у меня нет файла символов (код компилируется третьей стороной). Однако, если это единственный вариант, тогда, я думаю, мне придется спросить, могут ли они предоставить файл символов. Так что более того, если у меня есть способ рассчитать смещение, для меня это более быстрый процесс в данном конкретном случае. Neil Coffey

Ваш Ответ

2   ответа
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 не было вырезанных символов.

Спасибо - это сработало только с двоичным файлом (в котором действительно не было удалено символов). Neil Coffey
5

__TEXT сегмент к относительному адресу, указанному в аварийном дампе. Результатом является адрес, который нужно искать в разборке. Вот шаги:

Use otool -lv <application-binary> to dump the load commands from the application binary. Look for the load command for the __TEXT segment and the associated value for vmaddr, typically 0x1000. You don't need the information about the __text section that is shown above, just the information about the segment.

In the crash dump, addresses in the call stack are given in the form 0x00124ff4 0xf4000 + 200692. The last part is an offset within the binary in decimal. Add this to the value obtained in step 1 and convert to hexadecimal. In this example, we would calculate 0x1000 + 200692 which is 0x31ff4 in hex.

Use otool -tV <application-binary> to dump disassembly for the application binary. Locate the address obtained in step 2 (0x31ff4 in this example). For the topmost frame of the call stack this is where the application crashed. For all other levels, at the calculated address should be a branch instruction which corresponds to the next higher level in the stack.

Похожие вопросы