What is __aeabi_unwind_cpp_pr1' and how can I avoid it?

Question

I have a bunch of arm assembly, C and C++ files. gcc is trying to link them, but these are for an embedded project.

I am not using any external libraries, all code that is being used was written by me. An error seems to happen because I have a function called int kernel_main(void) defined in main.c that is trying to call set_LED(int value) defined in mailbox.cpp which includes the header mailbox.h (I did include the header in the main.c file).

The exact error is:

undefined reference to `__aeabi_unwind_cpp_pr1'

The way I am making my project is: -compile all source files (.s, .c, .cpp) into object files (.o) without linking (-c), then link them all together with the use of a custom linker script.

Edit: I am going to add some information to make things more clear.

First changing all files so that all of them are C files (no cpp extensions) yields:

undefined reference to `set_LED'

It is unlikely that the issue itself is name mangling an it probably has nothing to do with CPP and C differences.

The problem is very likely to be a linker issue

This is the build process:

Compile c files, Example:

arm-none-eabi-g++ -O0 -march=armv8-a source/MainFiles/mailbox.cpp -nostartfiles -c -o objects/MainFiles/mailbox.o

(Compiling a C++ file would be identical except for the use of g++ instead of gcc)

Link everything:

arm-none-eabi-ld object1 object2... -o build/kernel.elf -T ./source/kernel.ld -I include_directory_1 -I include_directory_2 -L include_directory_1 -L indlude_directory_2

Include directories are all directories under the current one

Edit: The error came back. Ignore the parts of this question relevant to name mangling. The error I need to fix is:

./objects/Hardware/mailbox.o:(.ARM.exidx+0x18): undefined reference to `__aeabi_unwind_cpp_pr1'

So far all I know is that this has something to do with unwinding the stack and exceptions. It seems the function is defined in libgcc. However I have used -nostdlib, I have omitted it, and in both cases the error persists. I have tried changing file extensions to .c whenever possible and to .cpp whenever possible, alas the error is always there.

It got fixed only as long as I had exactly 1 cpp file and the rest of my files were C files (this is no longer true, I tried). What triggered the error again was that I was refactoring the code and I wanted to move a couple of functions to new files.

In other words, without deleting a single file, declaring a function named wait(uint32_t time) in mailbox.cpp works, declaring it in a file called time.c (or cpp) with it's respective header declaration and including the header in mailbox.cpp breaks things. Note I don't delete the files when moving the function I simply delete the function declaration inside each file.

Adding a stub like this:

void __aeabi_unwind_cpp_pr1()
{

}

Fixes the problem and the code works. But I don't like this solution. I don't want a useless stub being called mysteriously in my code. I don't need nor want this function in my current implementation, how can I tell the compiler or the linker that they are to omit whatever they are doing that requires this function?

Answer 1

Please also add prefix "-shared" without quotes to -fno-exceptions. I am using ARM GCC version

Answer 2

The solution is very simple. As it turns out exceptions are enabled by default (which is what generates the code that calls __eabi_unwind_cpp_pr1). To disable them all that is needed is to pass: -fno-exceptions as an argument to the gcc/g++ compiler and the problem is solved.

Answer 3

I have seen this when mixing C and C++. Because of name mangling, the symbols will have different names internally depending on the type of the source file.

If the source for 'set_LED'is a c file, use the following in the header around the prototype and see if it helps.

#ifdef __cplusplus
extern "C" {
#endif

// function prototypes here

#ifdef __cplusplus
}
#endif

Answer 4

You have a reference to this function that belongs to the C++ runtime of GCC. It's part of the exception handling. Whatever you are doing, sounds a little crazy, but anyway you can do this if you really know what you are doing. You must link against the C++ runtime libraries. That's it. Link against "libstdc++".

About the set_LED I also believe it's just about the C++ mangling, just as Justin J mentioned in the other answer.