Возникла потребность написать обработчики исключительных ситуаций, которые помогли бы отыскать причину их возникновения.
Пытаюсь реализовать это для at91sam7x. С data abort примерно всё понятно, почитав регистры Memory Controller и abort link register, получаю точное место ошибки. А prefetch abort поставил меня в тупик. Сам exception возникает довольно часто если случается такая ситуация например: вызов функции по неинициализированному или кем-то затертому указателю. И соответственно ядро пробежав немного по левым адресам спотыкается и улетает в аборт, соответствено контроллер памяти и регистр возврата содержат левые адреса, по которым невозможно вычислить откуда ноги растут.
Возникла идея восстановить режим из теневого регистра статуса, почитать sp и сам стек, восстановить режим обратно, а по считанному стеку найти виноватого. Но это чистой воды хак, так как процессор переходит из режима в режим по исключительным ситуациям, а возвращаться рекоммендуют спец. командами (см. спецификацию). И вот у меня иногда это хак проходит успешно, а иногда при смене режима руками, неожиданно меняется регистр pc и программа улетает по адресам возникшим в pc. Может кто знает какие тайные тропы, как почитать стек одного режима ядра в другом режиме.

Это не хак, а вполне нормальный метод.


Если Вы не забыли отключить прерывания при переключении режимов, то процессор никуда улететь не может по определению.

Вот пример, пользуюсь все время. Выводит в UART адрес исключения, дамп регистров и дамп стека до аборта. Собственно UART не прилагаю. Там понятно из названия функций.
Поддерживает только ARM режим. Для THUMB не стал заморачиватся, потому как не исползую его.

А в чем заключается принципиальное отличие для Тумбы?
На мой взгляд дампы-то одинаковые будут, посему должно работать для обоих режимов. Разница возможна только в адресе по которому произошло исключение - в тумбе может отображаться как +1. Возможно, что в коде Вашем для Тумбы ничего менять и не нужно. ;>

Под Thumb не заработает. Как раз мой случай. Когда восстанавливаешь предыдущий режим необходимо флажок Thumb в SPSR подавить иначе дальше вектор исключения начнёт выполнятся через строчку и в итоге улетит по непонятным адресам. Вроде как разлбрался и заработало.

З.Ы.
Спасибо всем ответившим. Особенно за пример кода, много что полезного для себя там увидел.

Спасибо, как раз вчера искал внезапный DABT, очень не хватало, писать времени не было... Нашел мозгом.

Так поделитесь поддержкой THUMB с общественностью.


Количество регистров другое, адрессация другая, CPSR чуть другой, для получения дампа нужно определить, что был таки THUMB, переключится в него, снять дамп, вернутся назад в SYS, потом еще назад в ABD.

Все не так.
1. Количество регистров то же.
2. Адресация - та же.
3. CPSR тот же.
(собсно откуда взяться новым или куда пропасть регистрам, как им видоизмениться если ядро одно и то же).

4. для получения дампа определить был или не был Thumb - не нужно.
(Thumb это фантазия системы команд, на содержимое памяти/регистров она никак влияет)

5. переключаться в Thumb - не нужно. В ARM режиме есть доступ к той же памяти и к тем же регистрам.

6. вернуться в SYS? из Thumb?! не нужно (т.к. мы и так в SYS) ARM/Thumb и ABT/SVSR/USR/IRQ/FIQ - это абсолютно разные параллели не надо их смешивать...
7. Вернуться в ABT? зачем? произошел краш, чего еще ждать от системы? После снятия дампа самое время делать рестарт (по WDT или другим путём).

Единственная проблема, которую уже отметили, это то - чтобы проц неожиданно не переключился в Thumb исполняя ARM инструкции. Т.е. надо гасить флаг T в SPSR.


PS: Интересно как Вы себе представляете ARM/Thumb interwork если бы было столько отличий сколько Вы написали?!

Так собственно defunct всё описал уже. Ничего специального для режима thumb я не делал. Добавил только строчку:

чтобы убирать битик thumb режима.