Обычно, чтобы понять проблему, вам понадобятся каждый регистр (от r0 до r15), CPSR и верхняя часть стека (чтобы определить, что произошло до сбоя). Также обратите внимание, что когда ваша программа прерывается для любой недействительной операции (переход на недействительный адрес, ...), процессор переходит в режим исключения, тогда как вам нужно сбрасывать регистры и стек в контексте вашего процесса.
Чтобы иметь возможность исследовать, используя эти данные, вы также должны хранить файлы ELF (с возможностью отладки, если это возможно) из своей сборки, чтобы иметь возможность интерпретировать содержимое ваших регистров и стека.
В конце концов, чем больше информации вы храните, тем легче отладка, но может быть дорого хранить все разделы памяти, используемые вашей программой во время сбоя (по сути, я никогда не делал этого).
В патологоанатомическом анализе, вы будете сталкиваться некоторые ограничения:
- Динамически связанные библиотеки: если ваш сбой в динамически загружаемой и связанного кода, you will also need the lib binary you are using on your target.
- Повреждение памяти: повреждение памяти обычно приводит к вызову случайных данных в виде кода. В ARM с linux это, вероятно, приведет к segfault, поскольку вы не можете перейти в другую область памяти процесса, и поскольку ваши данные, вероятно, будут отмечены как «никогда не выполняться», тем не менее, когда произойдет сбой, вы можете иметь уже повреждены данные, которые могли бы позволить вам определить источник коррупции. Анализ postmortem не всегда способен идентифицировать причину отказа.
Если вы не знали, это может помочь узнать, что у некоторых ARC SoC есть [Встроенный трассировочный буфер] (http://infocenter.arm.com/help/topic/com.arm.doc.set. coresight/index.html # tracebuffers), чтобы делать именно такие вещи в оборудовании. – Notlikethat
@Notlikethat Спасибо за вашу полезную информацию. В самом деле, я не знал об упомянутых функциях Trace HW. Я буду смотреть в него. –