C ++ обработчик исключений на GNU Arm Cortex M4 с freertos

Обновление 2016-12
Теперь есть и минимальный пример такого поведения: https://community.nxp.com/message/862676

Я использую ARM Cortex M4 с freertos, используя свободную свободную версию Kinetis IDE (набор инструментов gnu arm). Проблема в том, что

try {
throw 4; // old scenario also not working: throw std::runtime_error("wut");
} catch (...) {
}

приводит к остановке ЦП и коду после попытки или (при добавлении некоторого) в обработчике catch не выполняется.

А сборка может быть найдена здесь: https://gist.github.com/Superlokkus/3c4201893b4c51e154e2a0afdf78fef0

Я предположил, что это приводит к прерыванию SVC, извините, что я ошибся, Freertos обманул меня, потому что, когда я что-то выбрасываю, он останавливается в DefaultISR.

Индекс бросков прыгает к __cxa_throw затем оттуда к ___Unwind_RaiseException __gnu_Unwind_RaiseException __cxa_begin_catch>
<_ZSt9terminatev>
Так выглядит std::terminate называется, но блок catch all не должен допустить этого. Или мое предположение неверно, и это происходит потому, что поддержка исключений среды выполнения gcc C ++ является заглушкой, которая всегда вызывает terminate ?!

Обновление 2016-09: Поскольку я видел, что rand () пытается использовать malloc (), я также определил рабочую функцию malloc () / freeRTOS и т. Д. Voilà: __cxa_allocate_exception использует malloc (интересно, как связка инструментов ожидает, что я обработаю случай bad_alloc).
Так что теперь, это все еще дает сбой, но после выделения исключений (я думаю):
Путь исключения:

(throwing function after exception allocation)
__cxa_throw
...                        //(some intructions in __cxa_throw)
__cxa_begin_catch  //I guess something went wrong here
_ZSt9terminatev // Immediately after __cxa_begin_catch
_ZN10__cxxabiv111__terminateEPFvvE:
00016dfc: push {r3, lr}
00016dfe: blx r0  //Goes directly to WDOG_EWM_IRQHandler or hard fault handler
00016e00: bl 0x194ac <abort>

Если вам интересно, или это может помочь: мои отладчики говорят, что это WDOG_EWM_IRQHandler, в который я вхожу, если я не определяю обработчик hard_fault и собственный обработчик по умолчанию.

Таким образом, я предполагаю, что что-то пошло не так в размотке стека, потому что я прошел через некоторые символы с «разматыванием готового стека» в имени в _throw, но я не поймал точку останова, которую я установил в деструкторе объекта, который должен был быть убрано. И это, кажется, мотивирует __cxa_begin_catch вызывать прерывание или что-то в этом роде.

(Студия дизайна Kinetis 3.2.0. С
Кросс-компилятор GNU ARM C / C ++
Версия: 1.12.1.201502281154
за наших
FRDM-KV31F)