Rather than computing an absolute path relative to Swift's resource
directory, use the compiler driver to locate the profiling runtime
relative to the C/C++ compiler's resource directory. This ensures that
we correctly locate the runtime. Additionally, because clang adds the
clang resource directory to the library search path, we do not need to
compute the path and can rely on the linker locating the runtime via the
library search path. This simplifies the handling for the profile
runtime linking on Windows.
Out of abundant paranoia, place the library link request after the
forced symbol inclusion as a GC root to ensure that `/opt:ref` will not
accidentally dead strip the symbol and force a reload of the library.
The Windows linker does not support `-u`. Furthermore, the compiler
driver does not forward the `-u` option to the linker. We correctly use
the `/include:` option from the linker. This should ensure that the
symbol is preserved even with `/opt:ref`. This spelling should be
compatible with both lld and link, which should provide sufficient
portability.
Take the opportunity to make it more obvious that the two parameters are
creating a pair that will be concatenated by using a braced initializer.
See
https://docs.microsoft.com/en-us/cpp/build/reference/include-force-symbol-references?view=msvc-160
for more details on the option.
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.
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.
Rather than aborting due to an assertion failure, emit a diagnostic.
This is much safer and generally easier to understand why the command
failed. It solves the problem of running swiftc from the build without
the path being set such that the clang++ driver is found by the swift
driver.
The librarian on Windows is a part of the linker. Enabling `-use-ld=`
for driver for static linking on Windows enables the user to override
the linker. This is particularly important for cross-linking Windows
from Linux where link.exe is not present as it is a part of the MSVC
toolset.
On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
The object file extension on Windows is `.obj` rather than `.o`. Ensure
that we get the extension correct when compiling for Windows.
Furthermore, ensure that we install with the correct extension when
installing a cross-compiled image. As we may be using the homegrown
cross-compilation system, we must explicitly handle the extension
ourselves. This allows nearly a 100 additional tests to pass on
Windows.
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.
