When compiling a C program for ARM Linux, you can easily end up with dependencies on libgcc_s. This is very annoying as it is not how other targets behave and it means extra work to make binaries that work on a lot of system.
I tried to understand the issue, and from what I gather the ARM EABI has a more advanced stack unwinding system that involves calling functions. This combined with helpers in libgcc.a for U64 division that can throw exceptions, results in a dependency on libgcc_s.
First question: Why are these libgcc.a functions being built with unwind tables? The stated reason is because of CPU exceptions, but AFAIK those result in signals, not language level exceptions?
Second question: Let's assume libgcc.a truly needs the unwinding, or if nothing else there will be other C code that is compiled with -fexceptions for compatibility; can we remove the hard NEEDED for libgcc_s and only use it if some C++ (or similar) code pulls it in?
I think the answer to the second question is yes. We've applied the attached patch to our gcc and it seems to do the trick. C code will not have libgcc_s as NEEDED, yet you can still throw exceptions just fine, even across C code compiled with -fexceptions.
I am a bit concerned about the interaction of weak symbols in a static library (libgcc.a) and versioned symbols in a "proper" library (libgcc_s.so). Comments?
Created attachment 32266 [details]
patch to weaken unwind symbols
Created attachment 32267 [details]