This commit adds LTO support for handling linker options and LLVM BC
emission. Even for ELF, swift-autolink-extract is unnecessary because
linker options are embeded in LLVM BC content when LTO.
This doesn't yet allow including C++ headers on platforms where libc++
isn't the default; see comments in UnixToolChains.cpp for details.
However, it does, for example, allow throwing and catching exceptions in C++
code used through interop, unblocking
https://github.com/apple/swift/pull/30674/files.
The flags (-enable-experimental-cxx-interop and -experimental-cxx-stdlib) carry
"experimental" in the name to emphasize that C++ interop is still an
experimental feature.
Co-authored-by: Michael Forster <forster@google.com>
This commit adds -lto flag for driver to enable LTO at LLVM level.
When -lto=llvm given, compiler emits LLVM bitcode file instead of object
file and perform thin LTO using libLTO.dylib plugin.
When -lto=llvm-full given, perform full LTO instead of thin LTO.
Handle `-no-toolchain-stdlib-rpath` on Linux/android as well as Darwin. This
enables the flags on other Unix platforms as it can be useful to control the
embedded rpath for the library.
Add the platform conditional and set up other basics for the toolchain.
The ConditionalCompilation tests are updated to match, since otherwise
they seem to trip when building on non-OpenBSD platforms. The
Driver/linker test is updated to ensure lld is passed on this platform.
Note that OpenBSD calls "x86_64" as "amd64", so we use that name for the
architecture instead of trying to alias one to the other, as this makes
things simpler.
Now that CMAKE_HOST_SYSTEM_NAME and CMAKE_SYSTEM_NAME are set by default to
Android in the Termux app, make the needed tweaks. Some tests were adapted
to work natively on Android too, adds sys/cdefs.h to the Bionic modulemap,
and includes the start of native Android platform support in the build-script.
Currently we only support building for android armv7, arm64, x86,
x86_64. In the future, if support for MIPS and MIPS64 is added, we
should normalise those as well. This is needed to support compilation
against modern NDKs.
Use `clang` rather than `clang++` as the linker driver. This ensures
that we do not force a C++ runtime on the general code. This is fine
for now as C++ interop is not yet available for Swift. This prevents
the accidental mix-and-match of various C++ runtimes. This can cause
problems on platforms like android where `libstdc++` is an unsupported
runtime but is generally the default for Linux platforms.
Previously, the TSan runtime only required libdispatch on Darwin, which
required no explicit linker flags, because libdispatch is always
provided by the system (libSystem).
Now, the TSan runtime also has a link-time dependency on libdispatch on
Linux, where libdispatch (and the blocks runtime) is just another
library. We therefore need to specify them as additonal linker options.
In the Darwin toolchain the linker is invoked directly, and compiler_rt
is used if it is found, but in Unix platforms, clang++ is invoked
instead, and the clang driver will invoke the linker. Howerver there was
no way of modifying this clang++ invocation, so there's no way of
providing `--rtlib=` and change the platform default (which is normally
libgcc). The only workaround is doing the work that the Swift driver is
doing "manually".
The change adds a new option (with help hidden, but we can change that)
to allow providing extra arguments to the clang++ invocation. The change
is done in the two places in the Unix and Windows toolchains that I
found the clang driver was being used.
Includes some simple tests.
This change allows the swift driver to link the ubsan runtime if
`-sanitize=undefined` is specified.
This is useful for sanitizing linked Objective-C code.
This enables response files for any jobs that invoke `swift` or another
toolchain tool that goes through the same driver code path, like
`swift-autolink-extract`.
Previously extra linker arguments had different behavior on darwin vs
other unix platforms. On darwin the arguments passed with -Xlinker would
be passed to the linker before the default arguments, where as with the
default unix toolchain they would be passed afterwards.
There isn't really a great option for which order these should be in.
If you want to have a custom rpath that takes precedence over the
default rpaths, you want them to be passed before, but if you want to
negate a default argument you want them to come after.
This change unifies the behavior so at least you always get the same
behavior across platforms.
