preparation of further LLVM merges.
MFC r307230 (by emaste):
Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation
They are not yet connected to the build, but I am adding them to allow
for easier testing, ports exp-runs, etc.
Reviewed by: ed
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8188
MFC r307231 (by emaste):
libgcc_s: add libm dependencies from div{d,s,x}c3
compiler-rt's complex division support routines contain calls to
compiler builtins such as `__builtin_scalbnl`. Unfortunately Clang
turns these back into a call to `scalbnl`.
For now link libm's C version of the required support routines.
Reviewed by: ed
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8190
MFC r307864 (by emaste):
Move the LLVM-based libgcc_s to /lib
When enabled, it should install in the same location as the existing
library.
Reported by: antoine
MFC r308001 (by emaste):
libgcc_eh/libgcc_s: apply hidden visibility only to static libs
MFC r308100 (by emaste):
compile libunwind c source with -fexceptions
When an exception is thrown the unwinder must unwind its own C source
(starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to
be built with unwinding data.
MFC r308294 (by emaste):
libgcc_s: make unspecified shlib symbols local
We want only symbols explicitly specified in the Version.map.
Sponsored by: The FreeBSD Foundation
MFC r308308 (by emaste):
Connect new LLVM-based libgcc_eh & libgcc_s to the build
Compiler-rt and LLVM's libunwind provide a suitable replacement for
libgcc.a, libgcc_eh.a, and libgcc_s.so.
Remove the now-unused LLVM_LIBUNWIND block from gnu/lib/libgcc.
PR: 213480 [exp-run]
Reviewed by: brooks, ed
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8189
MFC r308379 (by emaste):
add __divdi3 and __udivdi3 to libgcc_s symbol version map
After r308294 they were missing on i386 (and previously were exported
only accidentally).
Reported by: antoine
MFC r308445 (by emaste):
add missing i386 symbols libgcc_s symbol version map
After r308294 they were missing on i386 (and previously were exported
only accidentally).
Reported by: antoine
MFC r312076 (by emaste):
libgcc_s: add libc DT_NEEDED to fix underlinking
PR: 216012
Reported by: jbeich
Sponsored by: The FreeBSD Foundation
MFC r316101 (by ngie):
Apply r315689 to lib/libgcc_s as well to unbreak the gcc xtoolchain build
lib/libgcc_s consumes lib/libcompiler_rt/Makefile*. The NO_WERROR.gcc in
lib/libcompiler_rt/Makefile doesn't seem to have made a difference in being
able to build this, so sprinkle NO_WERROR.gcc here as well.
Reported by: Jenkins (FreeBSD-head-amd64-gcc)
Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
MFC r320673 (by emaste):
Sort entries in libgcc_s Version.map
MFC r337585 (by dim):
In r308100, an explicit -fexceptions flag was added for the C sources
from LLVM's libunwind, which end up in libgcc_eh.a and libgcc_s.so.
This is because the unwinder needs the unwinder data for its own
functions.
However, for the C++ sources in libunwind, -fexceptions is already the
default, and this can have the side effect of generating a reference to
__gxx_personality_v0, the so-called personality function, which is
normally provided by the C++ ABI library (libcxxrt or libsupc++).
If the reference ends up in the eventual libgcc_s.so, linking any
non-C++ programs against it will fail with "undefined reference to
`__gxx_personality_v0'".
Note that at high optimization levels, the reference is usually
optimized away, which is why we have never noticed this problem before.
With clang 7.0.0 though, higher optimization levels don't help anymore,
since the addition of address-significance tables [1] in
<https://reviews.llvm.org/rL337339>. Effectively, this always causes a
reference to __gxx_personality_v0.
After discussion with the upstream author of that change, it turns out
that we should compile libunwind sources with the -fno-exceptions
-funwind-tables flags instead. This ensures unwind tables are
generated, but no references to any personality functions are emitted.
[1] https://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html
Reported by: jbeich
PR: 230399