libgcc_s: Add libm dependencies from div* functions
ClosedPublic
Actions

Authored by emaste on Oct 7 2016, 9:20 PM.

Details

Reviewers

dim
theraven
ed

Commits

rS307231: libgcc_s: add libm dependencies from div{d,s,x}c3

Summary

div{d,s,x}c3.c contain calls to builtins such as` __builtin_scalbnl`, which Clang turns back into a call to scalbnl.

For now link libm's C version of the required support routines.

Diff Detail

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

emaste updated this revision to Diff 21172.Oct 7 2016, 9:20 PM

emaste retitled this revision from to libgcc_s: Add libm dependencies from div* functions.

emaste updated this object.

emaste edited the test plan for this revision. (Show Details)

emaste added reviewers: theraven, ed, dim.

emaste added a parent revision: D8188: Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation.

emaste added a subscriber: bapt.

emaste mentioned this in D8188: Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation.Oct 8 2016, 12:04 AM

This is for the shared library used for unwinding, etc., right? Would there be any harm in just linking against libm dynamically?

In D8190#170144, @ed wrote:

This is for the shared library used for unwinding, etc., right? Would there be any harm in just linking against libm dynamically?

For unwinding as well as compiler runtime support. I don't really like introducing a nearly universal dependency on libm.

In D8190#171241, @emaste wrote:

In D8190#170144, @ed wrote:

This is for the shared library used for unwinding, etc., right? Would there be any harm in just linking against libm dynamically?

For unwinding as well as compiler runtime support. I don't really like introducing a nearly universal dependency on libm.

Makes sense. I was under the impression that libgcc_s was only used for stack unwinding, but it looks it's also linked in when building simple C apps. :-)

This revision is now accepted and ready to land.Oct 13 2016, 6:29 PM

In D8190#171242, @ed wrote:

Makes sense. I was under the impression that libgcc_s was only used for stack unwinding, but it looks it's also linked in when building simple C apps. :-)

Yes, these libraries are confusing. In summary:

libgcc.a contains compiler runtime support (e.g. 64-bit division on 32-bit processors)
libgcc_eh.a contains the exception handling stack unwinding code
libgcc_s.so contains both of the above for dynamically linked binaries