带有Freertos的Gnu Arm Cortex M4上的C ++异常处理程序 [英] C++ exception handler on gnu arm cortex m4 with freertos
问题描述
更新2016-12 现在，还存在一个针对此行为的最小示例: https://community.nxp.com/message/862676
Update 2016-12 There 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 the GNU ARM C/C++ Cross Compiler Version: 1.12.1.201502281154 for our FRDM-KV31F)
推荐答案
在Freescale Kinetis和在nxp社区上问同样的问题，NXP工程师Alice_Yang(假设使用NXP徽章)告诉我答案:
After successfully creating a blank project with default settings in freescales Kinetis, and asking the same problem on the nxp community, Alice_Yang , an NXP engineer (assuming by the NXP badge), told me the answer:
默认情况下，新项目链接到newlib-nano，该库禁用了它的异常支持.
The libstdc++ built along with newlib-nano have exception handling disabled.
因此解决方案是简单地链接到newlib.这可以通过简单地删除其他链接器标志"中的"-specs = nano.specs"行来完成.，并确保添加了相同选项的复选框也被禁用. 然后一切正常.仅ROM/文本大小的代码增加了27 kB，RAM/数据的代码增加了2kB.
So the solution is to link simply to newlib. This can be done by simply removing the line "-specs=nano.specs" in "other linker flags" and also make sure the check box which adds the same option is also disabled. Then everything works as expected. Only the code increased by 27 kB in ROM/text size and 2kB in RAM/data.
这篇关于带有Freertos的Gnu Arm Cortex M4上的C ++异常处理程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
