When using outline atomics on arm64 the compiler will create a call to
a function that performs the atomic operation. This allows us to use
the fastest operation depending on the hardware.

As these functions are implemented in libgcc create a linker script
so libraries that link against libgcc_s will include libgcc to pull
them in.

Reviewed by:	imp, jhb
Sponsored by:	Arm Ltd
Differential Revision:	https://reviews.freebsd.org/D45268

    [Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)

The compiler_rt helper functions have been built since 12.4, 13.1, 14
and anything newer.

This reverts commit bd27bd1f51d049538cc7a0053be9d99110a53ae1.

Only some people (including the release manager, unfortunately) ran into
build issues with the previous iteration of this commit, because they
were bootstrapping the compiler, either via the WITHOUT_SYSTEM_COMPILER
src.conf(5) setting, or because the build system determined that their
base system compiler was out of date.

The bootstrapped compiler would then enable outline atomics and compile
libgcc_s with these, but because libgcc_s is linked with -nodefaultlibs,
it could not find the helper routines in libcompiler_rt.a.

In contrast, people who did not bootstrap the compiler never saw any
issues, because libgcc_s was built using their 'old' base system
compiler, and so libgcc_s would not contain any calls to those helper
routines.

Fix this by ensuring that libgcc_s is linked against libcompiler_rt.a
explicitly, similar to some other binaries and libraries that are built
with -nodefaultlibs.

Also, bump FREEBSD_CC_VERSION to ensure that everybody gets the updated
compiler with outline atomics enabled. (This should have been done in
the first iteration of this commit, because the error would have shown
up right away then.)

MFC after:	3 days

This is a residual of the $FreeBSD$ removal.

MFC After: 3 days (though I'll just run the command on the branches)
Sponsored by: Netflix

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Reviewed by:	emaste
Differential Revision:	https://reviews.freebsd.org/D39328

This adds two new options WITH_ASAN/WITH_UBSAN that can be set to
enable instrumentation of all binaries with AddressSanitizer and/or
UndefinedBehaviourSanitizer. This current patch is almost sufficient
to get a complete buildworld with sanitizer instrumentation but in
order to actually build and boot a system it depends on a few more
follow-up commits.

Reviewed By:	brooks, kib, markj
Differential Revision: https://reviews.freebsd.org/D31043

As suggested in D27598. This also supports MK_WERROR.clang=no and
MK_WERROR.gcc=no to support the existing NO_WERROR.<compiler> uses.

Reviewed By:	brooks
Differential Revision: https://reviews.freebsd.org/D27601

This option was added as a transition aide when symbol versioning was
first added.  It was enabled by default in 2007 and is supported even
by the old GPLv2 binutils.  Trying to disable it currently fails to
build in libc and at this point it isn't worth fixing the build.

Reported by:	Michael Dexter
Reviewed by:	imp
Differential Revision:	https://reviews.freebsd.org/D24637

In original  GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version
for all architectures but ARM. For ARM should be publishes with GCC_4.3.0
version. This was originally omitted in r255095, fixed in r318024 and omitted
aging in LLVM libunwind implementation in r354347.

For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0
version , (because this is right original version) and again as
normal(not-default) with GCC_3.3 version (to maintain ABI compatibility
compiled/linked with wrong pre r318024 libgcc)

PR:	233664

GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or
EHABI or whatever it's called.  Export the same ones from LLVM-libunwind's
libgcc_s, on ARM.  As part of this, convert libgcc_s from a direct
Version.map to one constructed from component Symbol.map files.  This allows
the ARM-specific Symbol.map to be included only on ARM.

Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match
non-ARM definitions and ARM-specific expectations in libcxxrt /
libcompiler_rt.

No functional change intended for non-ARM architectures.

This commit does not actually flip the switch for ARM defaults from libgcc
to llvm-libunwind, but makes it possible (to compile, anyway).