Static Libraries losing capability to handle exceptions

[JasonJohn]

Hello! I'm currently having some issues with static libraries and exceptions.

I'm currently running a static library (consisting of "general" code not specific to the current project I'm working on) in conjunction with a standard project. The static library has exception handling internal to it, but as of right now no exception handling occurs over the library-project line. Unfortunately, it appears that the static library is unable to process any exceptions - not even those it generates itself - causing any exception within the static library to crash the program.

I've constructed a MWE in the following manner:

1) Created a C++ Project and a C++ Static Library project, using the SDK wizard. I'm using the MIMXRT1060-EVK, but I don't think this is board specific.

2) Enable exception handling in both the Project and Static Library (by changing -fno-exception to -fexception)

3) Include the following code in the static library

// library_example.hpp
class library_example
{
public:
	enum class ERRORS
	{
		SOMETHING_WRONG
	};

	void testThrow(void);
};

//library_example.cpp
#include "library_example.hpp"
void library_example::testThrow(void)
{
	int is_caught=0;
	try
	{
		throw ERRORS::SOMETHING_WRONG;
	}
	catch(...)
	{
		is_caught++;
	}
}

4) Compile

5) In the project, add the directory featuring library_example.hpp into the compiler include paths. Also add the directory featuring the library executable.

6) Add the directory featuring the library executable to the library search path in the linker. Also add the library name to the libraries list in the linker settings. (See attachment)

7) Include the following code in the project

#include "library_example.hpp"
int main(void) {
    library_example example;
    example.testThrow();
    while(1) {
        __asm volatile ("nop");
    }
    return 0 ;
}

  Compile. Put a breakpoint at is_caught++ and run. The expected behavior is that the thrown exception is caught, is_caught is incremented (just before it leaves scope) and then the program spins in place. However, instead, the program crashes on the throw and the catch section never sees the light of day.

My research so far have led me to some SE discussions saying that even exceptions across the boundary should be acceptable, never mind this situation where the exception handling is done in the same library. This had some promise that I was missing a -shared-libgcc, but to no avail. There's also this bit in the GCC documentation, but that seems to deal with handling an external exception, not this situation. The only problems I can think of is that I'm missing some obvious linking step that's crucial, but my research hasn't been able to find it and I'm about to drive myself insane. What's the obvious step I'm missing here?

[converse · Accepted solution]

Whic library are you using? I seem to recall newlib-nano does not support exceptions. Also which startup code are you using?

[JasonJohn]

Well, that was where my problem was.

Today I learned that the library headers was, in fact, not where the library is defined, but rather the library in the linker. So here I was thinking when I was just using newlib prime, when in reality it was newlib-nano all along...

Well, I have to find a way to detect if newlib-nano is being used to perhaps detect this issue in the future, but for now problem solved.