Compiler switch -fno-exceptions

[MattH]

As described on page [support.touchgfx.com/4.19/docs/development/ui-development/working-with-touchgfx/using-ides-with-touchgfx], building a TouchGFX project requires the compiler switch -fno-exceptions. The GCC options in the Makefile contain the switch.

I tried to change the switch to -fexceptions, and I could build and run my project (on an STM32H750B), which explicitly uses exception handling. All exceptions that will be thrown will be caught inside the application logic. All exceptions are intended to never reach the TouchGFX routines.

My question is now: What can go wrong?

Thank you in advance!

[Osman SOYKURT]

Hello MattH,

Indeed we recommend to let the -fno-exceptions option. If you decide to remove it, you'll will not be safe from a liking or a compilation error.

/Osman

[MattH]

Hello Osman,

thank you for your reply, really appreciate it. Regarding my question, I see, it was less precise than it should be 😉

Actually, I wanted to ask: What can go wrong at runtime?

I don't mind compile-time/link-time errors. In case they appear, I would have to solve them to get a runnable/deployable firmware anyway. What I care about is the situation at runtime: what could go wrong if there are no compile-time or link-time errors and I deploy my firmware which was built with exceptions enabled?

Thanks in advance!

[Pavel A.]

Hi @MattH​ Please refer to the GCC documentation on -fexceptions

From that info, it looks like -fexceptions deals with esoteric issue of propagating native platform exceptions to C++ language exceptions (try/catch).

This thing is very familiar to Windows developers, but less known elsewhere.

For example imagine that the program hits a HardFault and it is somehow wrapped and passed to C++ exception chain so that you can try/ catch it.

This requires low-level platform (OS) support, not available in bare metal environment.

Therefore there's no point to enable it, this would only increase the program size.

[MattH]

Hi Pavel,

thank you for your answer!

I have to admit, I don't comprehend what you mean by esoteric issue and propagating native platform exceptions to C++ language exceptions and thing is very familiar to Windows developers, but less known elsewhere. To my knowledge, exception handling is completely unrelated to Windows and can be used regardless of the operating system and is heavily used in a wide variety of C++ applications. I don't expect exceptions from HAL 😉 All possible exceptions inside my MCU application will be thrown by myself by methods/functions/procedures hitting an unrecoverable situation and will be caught by a particular caller in the call hierarchy which can handle this situation. Just the common exception concept.

As written in the GCC documentation, -fexception (or the absence of -fno-exceptions, what is the default) enables exception handling by providing exception propagation code. Without that code, I cannot use throw/catch. If I use throw/catch with -fno_exceptions, the compiler will complain; if I enable exception handling (by removing -fno_exceptions or changing it to -fexceptions), the compiler and linker create my firmware, the firmware does what it should and everything works as expected - inclusive the exception handling (throwing/catching), which I can even provoke when I test my software.

Since the default compiler switch is exceptions enabled, I thought there possibly is some information why TouchGFX deviates from that default. Could be, that it is all about saving memory; could be, that there is some crazy thread effect, or whatever reason forbidding the use of exceptions. And that's what I'm up for 🙂

[MattH]

Hi Pavel,

thank you for your answer!

I have to admit, I don't comprehend what you mean by esoteric issue and propagating native platform exceptions to C++ language exceptions and thing is very familiar to Windows developers, but less known elsewhere. To my knowledge, exception handling is completely unrelated to Windows and can be used regardless of the operating system and is heavily used in a wide variety of C++ applications. I don't expect exceptions from HAL 😉 All possible exceptions inside my MCU application will be thrown by myself by methods/functions/procedures hitting an unrecoverable situation and will be caught by a particular caller in the call hierarchy which can handle this situation. Just the common exception concept.

As written in the GCC documentation, -fexception (or the absence of -fno-exceptions, what is the default) enables exception handling by providing exception propagation code. Without that code, I cannot use throw/catch. If I use throw/catch with -fno_exceptions, the compiler will complain; if I enable exception handling (by removing -fno_exceptions or changing it to -fexceptions), the compiler and linker create my firmware, the firmware does what it should and everything works as expected - inclusive the exception handling (throwing/catching), which I can even provoke when I test my software.

Since the default compiler switch is exceptions enabled, I thought there possibly is some information why TouchGFX deviates from that default. Could be, that it is all about saving memory; could be, that there is some crazy thread effect, or whatever reason forbidding the use of exceptions. And that's what I'm up for 🙂

[MattH]

Sorry, wrong reply.