Bug 60428 - non-exception (e.g. C) ARM Linux programs depend on libgcc_s
Summary: non-exception (e.g. C) ARM Linux programs depend on libgcc_s
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.5.4
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-05 11:49 UTC by Pierre Ossman
Modified: 2014-11-17 14:23 UTC (History)
0 users

See Also:
Host:
Target: arm
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
patch to weaken unwind symbols (1.17 KB, patch)
2014-03-05 11:49 UTC, Pierre Ossman
Details | Diff
test case (671 bytes, application/x-xz)
2014-03-05 11:50 UTC, Pierre Ossman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Ossman 2014-03-05 11:49:09 UTC
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?
Comment 1 Pierre Ossman 2014-03-05 11:49:48 UTC
Created attachment 32266 [details]
patch to weaken unwind symbols
Comment 2 Pierre Ossman 2014-03-05 11:50:54 UTC
Created attachment 32267 [details]
test case
Comment 3 Pierre Ossman 2014-11-17 14:23:53 UTC
Comments?