> The __aeabi_unwind_cpp_pr* personality routines are *not* libunwind >functions either, they are also functions from libgcc_eh. Anything >related to those functions should not use the term "libunwind", >whether in configure option names, or patch submissions, since it is >not libunwind. Linking with libgcc_eh should work fine by default; >no special action should be needed to link in whatever unwind >functions your code references. But if you don't want to link them >in at all, and if defining your own versions of __aeabi_div0 / >__aeabi_ldiv0 doesn't suffice, then as long as your code doesn't >raise exceptions it should be safe for you to stub out the >__aeabi_unwind_cpp_pr* functions. -- Joseph S. Myers
Ok, just read the "Exception Handling ABI for the ARM Architecture". * From Section 6.2 "Bits 24-27 select one of 16 personality routines defined by the run-time support code. Remaining bytes are data for that personality routine. ... ARM has allocated index numbers 0, 1 and 2 for use by C and C++. ... Object producers must emit an R_ARM_NONE relocation from an exception-handling table section to the required personality routine to indicate the dependency to the linker." I think you are right, we need to stub out the __aeabi_unwind_cpp_pr functions. Thanks alot & Best Regards Fredrik