Merge additions of LLVM libunwind libgcc_eh and libgcc_s. This is in
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