libgcc_s: Add libm dependencies from div* functions

[emaste]

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.

[ed]

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

[emaste]

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.

[ed]

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. :-)

[emaste]

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