C++ exception handler on gnu arm cortex m4

David Brown david@westcontrol.com
Tue Sep 27 12:45:00 GMT 2016


On 27/09/16 11:31, Richard Earnshaw (lists) wrote:
> On 27/09/16 09:58, Markus Klemm wrote:
>> Hi folks,
>>
>> I'm using the gnu compiler suite for my arm cortex m4 project. But every
>> throw produces a hard fault, even on simple
>>
>> try {throw 4;} catch(...){}
>>
>> scenarios. __cxa_throw jumps right to _ZSt9terminatev, after
>> __cxa_begin_catch returns, which should AFAIK never return.
>>
>> Are there any common problems leading to this behavior?
>>
>> Specific I'm using Kinetis Design Studio 3.2.0. with the GNU ARM C/C++
>> Cross Compiler Version: 1.12.1.201502281154 for our FRDM-KV31F.
>>
> 
> I don't recognize any of the above in terms of an FSF GCC release, so
> there's little we can do to help, especially without a full test case.

The Kinetis is a family of ARM Cortex M4 and M0+ microcontrollers from
Freescale/NXP.  The Kinetis Design Studio is a toolchain package from
Freescale/NXP consisting of Eclipse, gdb (with OpenOCD and other
hardware interfacing), gcc, libraries, device-specific headers, wizards,
etc.

The gcc + friends package is from
<https://launchpad.net/gcc-arm-embedded> .  As far as I know, Freescale
does not modify it at all now - it is taken straight from that site,
though not necessarily the latest release.  The library is newlib or
newlib-nano (both are part of it).

The OP can probably get best support on this setup by posting to the
Kinetis Design Studio forums at Freescale/NXP, or on the forums on the
Launchpad site.

> 
> Have you checked that Kinetis are not disabling exception support in
> their libraries?  It's not uncommon for embedded code to do this since
> the overheads of exception unwind data and handling code can become
> quite significant.  Calling terminate when an exception is thrown is
> expected behaviour if exception undwinding is disabled.
> 
> R.
> 
>> I also created a stack over flow question with a +50 rep bounty:
>> http://stackoverflow.com/q/39468524/3537677
>>
>>
>> Markus Klemm
>>
> 
> 



More information about the Gcc-help mailing list