[Bug target/60428] New: non-exception (e.g. C) ARM Linux programs depend on libgcc_s

[ossman at cendio dot se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428

            Bug ID: 60428
           Summary: non-exception (e.g. C) ARM Linux programs depend on
                    libgcc_s
           Product: gcc
           Version: 4.5.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ossman at cendio dot se

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?