И где гарантия, что компилятор при очередной перекомпиляции, не разместит какие-то переменные в регистрах которые Вы хотели сохранить до вашей вставки?
Такое надо делать целиком в asm-функциях. Напишите ISR fault-ов полностью на asm, там всё элементарно.


Не знаю не знаю... У меня сохраняются все регистры + дамп стека. И то часто не хватает.


У меня все fault-ы примерно так же обрабатываются, только кроме дампа регистров сохраняю ещё и дамп текущего стека.
Отличия:
Для release-сборки: всё так же, кроме передачи на отладочный сервер.
Для debug-сборки: вместо перезапуска - переинициализация железа в минимальный дефолт-конфиг trap-режима и зацикливание в цикле периодического вывода инфы о событии в лог (UART). Чтобы не пропускать такие ошибки, а исправлять сразу.
Этот-же механизм используется для обработки программных критических ошибок (через SVC).


Помогает очень часто в обнаружении редко проявляющихся ошибок. Когда тестируем сразу несколько десятков (а то и сотни) устройств в течение длительного времени (дни/недели непрерывной работы).
С JTAG-ом тут не посидишь, а вот устройства защёлкнувшиеся в trap-цикле сразу видны. А потом - по регистрам-стеку ищем причину.
И если такие ошибки проявились уже на объектах заказчика - тут другого выбора нет, очень помогает.

Без дампа стека вообще мало когда эта инфа помогает. Типичная ситуация: срабатывание исключения MPU защиты памяти при попытке обращения к недопустимой памяти изнутри memcpy().
От регистров почти никакого толку - в каком месте кода произошёл сбой? Зато по стеку можно легко проследить цепочку вызовов. Уже сколько так багов нашли.

С легкой руки (для IAR)


Для CORTEX ядра все получается и без ASM функций.
А вот для ARM делал вставку на ASM с обработчиками исключений и функцией сохранения регистров.

В большинстве случаев эта информация помогает на столе.
В основном в исключения валимся при переполнении стека. Поэтому место возникновения исключения, при наличии RTOS, мало что скажет. Главное состояние планировщика, текущая задача(последняя в случае переключения контекста) и свободное место в стеке задачи.

Ещё раз: Где гарантия, что компилятор не вставит перед Вашей SaveContext() например создание стекового фрейма с занесением указателя на него в любой из R4-R11?
Типа:
PUSH {R7, LR}
ADD R7, SP, #N
...
или ещё чего, чего ему вздумается.

Как где? __stackless же. У gcc есть аналогичная штука - naked.

А это обязательное или только рекомендуемое как inline? А функции, которые из FaultHandler() вызываются тоже все __stackless?
И стек - это для примера. Что угодно, например - в какой-либо регистр может заранее положить указатель на секцию данных, либо какие-то другие данные.
Использование регистров внутри си-функции - по усмотрению компилятора, любые домыслы по их содержимому - потенциальные грабли.

jcxz, если делать что-то бездумно - то возможны любые грабли.
А если подумать - компилятор пытается лишь сделать то, что от него просят. И не больше.
Головой думать надо, прежде что-то делать.

Ну, ну. Я как-то на Си осмелился пописать под AVR. На меге8 килобайты флеш закончились настолько быстро, что захотелось узнать куда.
Листинг показал, что компилятор сохраняет в стек все регистры при вызове функций, даже неиспользуемые.
Отдельным приключением было сделать программный UART на Си - по тактам реализация очень неустойчива - на том краю планеты бабочка
махнет рукой (добавим, например, переменную в проект), а у нас пару лишних тактов в цикле задержки.
Что касается регистров, тактов и байтов - компилятор очень непредсказуемая штука.

Компилятор IAR так поступает при выключенной оптимизации (или невысоком уровне).

adnega, речь немного не про такой случай.
Использование стека еще как компиляторозависимо. От того, как он будет оптимизировать код, и какую оптимизацию ему разрешено использовать.
Уверен, и Вашему случаю нашлось бы объяснение в мануалах.

Здесь о том, что __stackless говорит компилятору, что стека НЕТ! То есть только регистры. И ничего он в них выделять не будет, пока не попросишь.

Да, и определитесь, что у вас закончилось, стек или флеш.... не вяжется как-то.

Тут советовали головой думать, но моя не может придумать - "зачем"?
Зачем неиспользуемые регистры складывать в стек??

Хотелось, чтобы основные "просьбы" к компилятору были в исходнике, а не различных ключах.
Именно поэтому есть задачки, не решаемые на С гарантированно, рассчитывать на здравый смысл компилятора я бы не стал.


Прошу без эмоций определить, что быстрее заканчивается при таком подходе

Это еще годный код, т.к. не все регистры убираются в стек, а только используемые.
Я описывал ситуацию, когда банальная установка переменной оборачивалась push-ами и pop-ами для всех регистров.
В моем случае резко закончилась флеш, хотя и к глубине стека требования резко возрастают.
Перед использованием С этот же проект был реализован на asm. При 10% asm-функционала на С закончился флеш.

Затем что оптимизации НЕТ. Делаем так, чтобы 110% все работало и отладка была удобной.
Определитесь для начала, какой результат хотите: быстрый, мало памяти занимал, или для отладки.
Программа не работала? Так какие претензии к компилятору?



Так да. Закончится и то, и другое.

На AVR почти не писал. А в ARM,как тут уже приводили, - одна инструкция хооть для всех регистров.

Ну-ну. И что же он пытается сделать? Расскажите-ка нам какие именно регистры задействуют все возможные компиляторы во всех возможных режимах оптимизации.
К Вашему сведению: компилятор имеет право использовать внутри функции любые регистры как ему заблагорассудится если это не противоречит соглашениям вызова.
Если думать именно головой, то как раз не надо делать никаких гаданий как именно будет построен код внутри си-функции.

jcxz, сравнивать неопределеность, исходящую от компилятора с определенностью, полученой от ручного кодирования машинных кодов (ASM) бессмысленно. ASM в выигрыше однозначно.
Но, вероятность получить "пасхальное яйцо" от компилятора примерно равна вероятности получить неработоспособный код со вполне работоспособных исходников.
Выбор всегда есть:
- хочешь сложное кодирование но 110% результат - пиши в машинных кодах,
- хочешь более легкое программирование и 100% результат - попытайся думать так, как думает компилятор.

И когда я говорю про компилятор, я имею ввиду конкретный, а не абстрактную сущность всех компиляторов.
К слову, ASM файлы тоже в большинстве случаев не переносимы.