void _trapISR _AddressError(void) -- опять не в тему. Такое я сам давно написал, стек даже кое-как разматывает, в отличии от (где __builtin_return_address() без -fno-omit-frame-pointer не работает). Вопрос в чём, допустим, имели на стеке:
ret-address2
frame-pointer2
local-variables2
variables...
ret-address1
frame-pointer1
local-variables1
В функции с неизвестным адресом, вызванной из точки ret-address1, local-variables1 наехала на ret-address1 и засрала его. По возврату получили _AddressError(). Внутри которой смотрим и видим только ret-address2 (или даже ret-addressN) из которого можем вычислить что вызывалась вот эта функция, которая вызывала вот этот список функций (ret-address1 уже неизестный) в одной из которых вызвали функцию в которой всё навернулось. Где именно навернулось понять даааалеко не просто. frame pointer (W14 что ли) тоже естесственно попорчен.
IMHO, это вообще недостаток архитектуры, что ADDRESS ERROR вырабатывается при обращении по некорректному адресу в PC, а не по факту занесения некорректного значения в PC, или что в стек кладётся уже испорченный PC, а не его предыдущего значения. Или я что-то не понимаю?
На ARM архитектуре хотя бы уцелел LR регистр, в котором было бы понятен ret-address1 (но запорчен сохранённое на стеке значение LR для ret-address2) и область поиска места сбоя ограничивалась бы исключительно телом функции вызвавшей
сбой -- чушь, там может засраться сохранённый в стеке LR и дальше всё то же самое.
Тут же остаётся подумать в сторону -finstrument-functions (а оно работает?), но это дикий оверхед. А хотелось бы возможности разбора ситуации постфактум на серийных изделиях.
fk0, легенда (26.01.2012 01:47 - 02:07, просмотров: 301) ответил MBedder на %C30%\support\templates\c\traps.c, заточить рашпилем по вкусу
)