Page MenuHomeFreeBSD

libgcc_s: Add libm dependencies from div* functions
ClosedPublic

Authored by emaste on Oct 7 2016, 9:20 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 21, 7:08 AM
Unknown Object (File)
Sep 26 2024, 7:50 PM
Unknown Object (File)
Sep 11 2024, 1:47 PM
Unknown Object (File)
Aug 23 2024, 10:16 PM
Unknown Object (File)
Aug 20 2024, 12:32 PM
Unknown Object (File)
Aug 20 2024, 12:32 PM
Unknown Object (File)
Aug 20 2024, 12:32 PM
Unknown Object (File)
Aug 20 2024, 11:53 AM
Subscribers

Details

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

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

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 subscriber: bapt.

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.

ed edited edge metadata.
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
This revision was automatically updated to reflect the committed changes.