带有Freertos的Gnu Arm Cortex M4上的C ++异常处理程序

本文介绍了带有Freertos的Gnu Arm Cortex M4上的C ++异常处理程序的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

更新2016-12 现在，还存在一个针对此行为的最小示例: https://community.nxp.com/message/862676

Update 2016-12There is now also a minimal example for this behavior: https://community.nxp.com/message/862676

我正在使用带有Freertos的ARM Cortex M4，并使用了Freescales Freedom Kinetis IDE(gnu arm工具链).问题是

I'm using a ARM Cortex M4 with freertos using freescales freedom Kinetis IDE (gnu arm toolchain). Problem is that

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

未执行catch处理程序中的try或(添加了某些内容时)将导致CPU和代码停止运行.

results in a halted CPU and code after the try or (when some is added) in the catch handler is not executed.

可在此处找到汇编: https://gist.github.com/Superlokkus/3c4201893b4c51e154e2a0afdf78f/a>

And assembly can be found here: https://gist.github.com/Superlokkus/3c4201893b4c51e154e2a0afdf78fef0

我断言这会导致SVC中断，对不起，我错了，Freertos欺骗了我，因为当我在DefaultISR中抛出某些内容时，它就会暂停.

I ASSUMED that this results in an SVC interrupt, I'm sorry I got that wrong, Freertos tricked me into this, because when I throw something it halts in DefaultISR.

投掷确实跳到 __ cxa_throw，然后从那里跳到___Unwind_RaiseException __gnu_Unwind_RaiseException __cxa_begin_catch> < _ZSt9terminatev> 因此，看起来像std::terminate被调用了，但是catch all块不应该允许这样做.还是我的假设是错误的，并且这种行为是因为gcc C ++运行时异常支持是一个总是调用终止的存根?！

The throw indeeds jump to __cxa_throw then from there to ___Unwind_RaiseException __gnu_Unwind_RaiseException __cxa_begin_catch> <_ZSt9terminatev>So it looks like std::terminate is called, but the catch all block should not allow this. Or is my assumption wrong and this behavior is because the gcc C++ runtime exception support is a stub which always calls terminate?!

更新2016-09 :因为我看到rand()尝试使用malloc()，所以我还定义了一个有效的malloc()/freeRTOS函数，等等:__cxa_allocate_exception使用malloc(我想知道工具链如何期望我处理bad_alloc情况).所以现在，它仍然崩溃，但是在异常分配之后(我认为):执行路径为:

Update 2016-09: Because I saw that rand() tries to use malloc(), I also defined a working malloc()/freeRTOS function and et voilà: __cxa_allocate_exception uses malloc (I wonder how the toolchain expects me to handle a bad_alloc case).So now, it still crashes, but after exception allocation (I think):The excecution path is :

(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>

如果您想知道还是可能有所帮助:如果我没有定义hard_fault处理程序和自己的默认处理程序，我的调试器会说是我崩溃的WDOG_EWM_IRQHandler.

If you wonder or it might help: My debuggers say its the WDOG_EWM_IRQHandler I crash into, if I not define the hard_fault handler and an own default handler.

所以我想堆栈展开时出了点问题，因为我经过了_throw名称中带有完成堆栈展开"的符号，但是我没有抓住在对象的析构函数中设置的断点，应该已经清理了.这似乎促使__cxa_begin_catch调用中止之类的东西.

So I guess something went wrong in the stack unwinding, because I go thru some symbols with "finished stack unwinding" in the name in _throw, but I didn't catched the break point I set in a destructor of an object which should have been cleaned up. And that seems to motivate __cxa_begin_catch to call abort or something.

(Kinetis Design Studio 3.2.0.GNU ARM C/C ++交叉编译器版本:1.12.1.201502281154为了我们FRDM-KV31F)

( Kinetis Design Studio 3.2.0. with theGNU ARM C/C++ Cross CompilerVersion: 1.12.1.201502281154for ourFRDM-KV31F)

带有Freertos的Gnu

带有Freertos的Gnu Arm Cortex M4上的C ++异常处理程序

问题描述

推荐答案