Hi all

I'm trying to port some code with a try ... catch block for exception handling, and get the message "Support for exception handling is disabled; use --exceptions to enable (E540)".

Would it be normal to have exception handling available for use with a device like the mbed, or does this add some kind of unacceptable overhead?

If it would be ok, how do we access the switch - I'm guessing that a lot of options are locked down because of the web interface to the compiler.

Thanks
Daniel

PS I never did like "on error goto" so please don't tell me that's a workaround ;-)

Hi Daniel,

The conventional wisdom (and the advice from the armcc compiler guys) is that the overhead of exceptions is pretty high and therefore not appropriate for this sort of domain. For now, we are therefore not supporting exceptions (it is hard to remove support, but easy to add it).

We'll definitely look at really understanding the space and time overheads at some point (mbed isn't really conventional, so perhaps exceptions are perfect!), but for now you'll have to stick to more conventional exception handling approaches.

Simon

Hi Simon,

I wonder if exceptions handling is available meanwhile.

Could you please give me a status?

Thank you in advance and best regards

Juergen

Hi Juergen,

We don't support exception handling in the compiler, and it is not planned to add it. But i'd be happy to hear about how you usually use them in your microcontroller applications, or your experiences! But for now, you will have to turn to more standard C solutions.

Thanks,

Simon

Hello Simon,

thank you for your answer. Unfortunately my robotics specialist who developped a 3-axis robotic conversion matrix  calculation  for me where "divide by zero, ..." errors in the matrix calculation should be catched, checked the mbed infos before starting the software development and found support of exception handling for mbed:

He found there: http://mbed.org/handbook/mbed-Compiler the link to the "ARM RVDS (v4.0)" :

http://www.arm.com/products/tools/software-tools/rvds/arm-compiler.php

where under "Accurate Code Generation" he found:

"[...] The default library selected by the ARM Compiler offers a full complement of C/C++ functionality, including C++ exception handling and IEEE 754 floating point support. [...]"

Whith this info he relied on "exception support" for mbed and developped the libraries and program accordingly.

It seems that our robtics programming expert relied on the info on mbed homepage and we wasted a lot of money if exceptions are not supported. To remove the exceptions will cost us additiononal money and we will have worse functionality.

Do you have a solution for me with exception-support to compile the code perhaps locally or so?

Please take into account that I'm not a software speciallist, more a beginner.

If mbed does not plan to support exceptions please update the homepage and clearly point out this to avoid other users to waste time and money.

Thank you very much for your help in adance and best regards

Juergen

Hi Jurgen,

Thanks for the information and use cases; very useful.

I've updated the compiler page to include "in the default configuration". For exceptions, the default configuration is no exceptions unfortunately, and this is especially appropriate for microcontrollers. The full RVDS compiler toolchain does have a wealth of options you can add (all sorts of knobs, tweaks, variables!), and we don't intend on exposing these. Our intention is to be a full but lightweight compiler toolchain without all the quirks and options, so everyone is playing to the same rules.

Others have had some success using the Keil compiler when they wanted to go offline (that is also based on RVDS compiler), and this provides access to and support for all these different types of options. You can see this example and a keil appnote they published. There is an eval version of the tool too, so you should be able to test it out too, so maybe this could be a good solution to try.

I will continue to look at whether the cost trade-off means we can introduce exceptions by default; I know the ARM RVDS team have been doing some great work on improving C++ performance, so will go and meet them again soon to get their advice. But I don't want to promise anything, so for now we do not support exceptions.

Hope that clears things up,

Simon

Is the zero division the only thing you needed exceptions for? Can you show some fragments of your code using exceptions?

I think you should be able to catch zero division with signal handlers and setjump/longjump. Or maybe you can set FP configuration to produce no exceptions on zero divide.

Easiest solution I can think of is to reimplement the div0 handler so it doesn't send an exception & just returns zero (say)

It's detailed here & here

Hi Simon,

thank you very much for your answer.

My suggestion would be a switch to turn on exceptions:

a) default: "exceptions off"  with all the positive small codesizes we see today.

b) "exceptions on" when somebody like me would need it and can accept bigger codesizes.

Thank you very much in advance and best regards

Juergen

I too would like to chime in here and request an option to turn exceptions on or off. There are times when I am trying to port a third-party library that uses exceptions, and it can quite a task to remove and/or replace the code with non-exception handling code.

As a bonus, I would like see other compiler options exposed as well. Particularly a way to turn off GNUC compatibility, since it really isn't fully compatible. One example is the Pawn scripting language which uses the GCC 'labels as values' feature to speed up the interpreter loop, but the RVDS compiler does not support this.

Thank you, Tyler

exceptions are implemented in hardware and are a tool during development (debug target) and make the system stable in the wild (resource management, error reporting, watchdog, etc.). I always use an exception framework when I do development (embedded or not). This platform has a lot more power than an 8 bit PIC or something like that. It can give the developer a lot of information at run-time to make debugging easier. In an emulator it allows for a lot more error information and breakpoints. It allows for less/no hardware debugging. It allows for conditional breakpoints when hardware debugging. It makes the resource management superior on release builds so you don't get apps that hang or crash the whole device when it runs out of memory, tries to connect to a device that is not connected, has a bad pointer for some reason, network hangs, etc. You can build really good error handling into an app but without exceptions you have no good way to handle general exceptions that was caused by a piece of code that was missed during testing and is in the field. A well designed framework is a couple levels deep in the stack. Macros allow you to remove code in the release builds so the result of an exception is a minimal amount of cleanup and reporting. If it is not a "terminal exception" the system can keep running. Otherwise it activates the action taken by a watchdog timer.

You're right, perhaps we should enable exceptions. Here's an article which argues against them: http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

my first impression of the article is that some of the people discussing the topic are inexperienced and have had issues with exceptions which is why they think they are hard. I don't know the people and I don't want to upset anyone, My views are based on reading through the comments. I don't know them and have not interacted with them. My view is that if you know the language (c++) then exceptions are not hard and you don't need to know much about them. You only need to know how the language and the cleanup works (virtual destructors). If you don't get too fancy you wont have problems. I am going to write some posts to follow that cover pieces of the "solution" that exception handing provides. I think everyone has used some device (my iphone 4) that runs out of memory (full of pictures) and behaves badly (apps crash and close) instead of recovering and reporting an error and remaining useful without rebooting.

I am not familiar with exceptions in C++ myself, but from some googling I end up that you need to have pretty much all code written in a specific way to be Exception safe. If thats true, you would need to modify/rewrite half the mbed lib, which is probably not exactly wanted.

Another potential issue I see is a split in the community libs: There is a trade off for complexity and speed/resources required, and many wouldn't want to include exception handling in their code, others would put it there.

All of the code doesn't need to be re-written. You can start using exceptions in your own code without changing the libs. If you use classes then the destructor is called automagically. You don't need to pull out error handling at all. I prefer to lightly sprinkle exception handling through the code. If you simply wrap a general exception handler around your main code in your debug builds and report errors it will be 100% better and your release targets will be unchanged because the code goes away.

Here is a simple project that uses simple macros and a C++ debugging object to report errors. There is a define in the debug.h file that tells it what kind of build it is. Usually you have build definitions and it is defined in the debug build. I didn't see any way to do that on the site so I am doing it this way.

https://developer.mbed.org/users/jimcooper/code/simple_debug/

Here is a simple project that shows how to add a simple general exception handler to your project without changing any of the libraries. I would have stack information in mine.

https://developer.mbed.org/users/jimcooper/code/simple_exception/

Here are a couple links that talk about the implementation of the exception handler in the chips. I have a M0 and a M4 so that is reflected in the links.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/BABBFABJ.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/ch03s09s01.html

Those are the standard stuff like hardfault handlers: If you want to use them you can simply define them in your code, no C++ exception handling code is required to use them properly. It is really unlikely though that if those are fired you are going to get any data back to your console, depending on how bad it went. You can probably still run NVIC_SystemReset :P.

By the way your second example shouldn't do anything, since divide by zero is not an exception in C++.

I'm working on other examples. You are correct about the hard fault. I don't have as much experience there and the exception code doesn't compile. I read more about it after the code was up. I was trying to introduce concepts that are easy to take in. I want inexperienced developers to be able to take it in.

@Jim Cooper: regarding the example you posted: any idea how the hardfault handler (invoked due to divide-by-zero) generates a C++ exception; something for me to discover.

This is a good example of a hard fault handler. I found it a while back. It does not generate a C++ exception. https://developer.mbed.org/users/rgrover1/code/DumpRegistersAtHardFault/

Jim, I happen to be the author of that handler. :)

Nice job. It is simple and easy to understand/ You have done more digging in the stack than I have. Sounds like the function call is gone from the stack by time the hard fault handler is called?

If the stack frame is there can you throw from the interrupt handler and roll everything back?

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FHard%20Fault%20and%20stack%20pushing&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=13779

Here's a better hard-fault handler https://github.com/feabhas/CM3_Fault_Handler, [https://blog.feabhas.com/2013/02/developing-a-generic-hard-fault-handler-for-arm-cortex-m3cortex-m4/]. I'll experiment with throwing a C++ exception from the hard-fault handler. I wonder if the C++ runtime is able to span the ARM-exception-handler boundary.

I have a fabulous use for Exceptions. I was absolutely appalled by the usage of sprintf in mbed RPC, so I spend WAY too much time making a RPC library to spank mbed hard. Y'all people need to stop using division and modulo operators. Y'all have been putting in modulo operators in the ring buffers and killing the performance. But anyway, what I'm doing with exceptions and why it is mandatory to have access to them in embedded situations is that I am using C++ exceptions to remotely crash processes. I have exactly one try-catch block at the beginning of the main. I've got multiple parameters for RPC and multiple return types (in the form of a Lamda function.). Anytime I'm scanning a function header (@see https://github.com/kabuki-starship/kabuki-toolkit/wiki/Script-Protocol-RFC for details) and I detect an interrupt, I can interrupt the system and shut the process down. I developed the technology because I was making a DNA extraction machine using high powered (40A) electromagnets. I had to be able to turn off the machine in case of ANY EXCEPTIONS!!!! The try-catch block is the only reliably portable way to crash processes and it's VERY clean code. Y'all like robust error detection and saving lives right?