The change to relax forced autolinking symbol emission restrictions
caused a regression due to over-fitting of the output where the
symbol's comdat annotation was not accounted for. Adjust the test
accordingly.
on behalf of the debugger. The debugger will read the LinkLibrary's
from all the modules it sees, and hand load all the required dependencies,
and since the symbol is weak it doesn't even tell us whether a
required dependency is missing. So it serves no purpose in this case.
<rdar://problem/51463642>
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
When Swift always copied the overlay dylibs into app bundles, it was OK
for these symbol references to be non-weak, but with the overlays now
part of the OS on Apple platforms, we need to handle backward deployment
scenarios where a new overlay does not exist on an old OS version.
A weak reference will serve to pull in the overlay dylib if it exists,
without causing a fatal error if it does not. rdar://problem/50110036
The OS sadly changes between Android ARMv7 and Android AArch64, to
avoid this and any future problems, mark the autolinking tests that
I can find with `UNSUPPORTED: autolink-extract`, which should apply
to all platforms that need autolink-extract.
This should remove these tests from failing in Android 64.
Use `ApplyIRLinkage` to the force load thunks to permit multiple
emissions to be COMDATed on Windows. The multi-module tests would emit
the symbols multiply and would fail to link.
We use dummy symbols to force overlays not to get dropped when
autolinking, even if the user doesn't use anything from them
explicitly. This behavior is triggered by the semi-hidden flag
-autolink-force-load.
(It's semi-hidden because it has few legitimate uses in real life. If
you searched for "how to force autolinking to pick up a library" and
found this commit, don't just do this and move on. Come talk to me on
forums.swift.org.)
Previously we added these dummy symbols to every object file using
"common" linkage, a little-known feature added for C that ensures that
only one definition will actually get used in the final object file.
However, the way we were doing that wouldn't work so well for COFF,
and so in 1025eed64 Saleem changed this to use "weak ODR" linkage.
This has *nearly* the same effect, and avoids some other weirdness,
but has the downside of making the symbol in the final dylib "weak"
itself, meaning that some /other/ library could come along and
override it. That impacts loading time, and an Apple-internal tool
caught that as rdar://39019606.
To avoid this whole mess, "just" emit the symbol into the object file
that corresponds to the first file in the module, which allows us to
mark it as a normal public symbol.
P.S. None of this is actually important at the moment because all of
the overlays are built with single-threaded WMO, which always produces
one object file anyway. But I wanted to get it right once and for all.
This was obscured due to local workarounds. Because the reference is
cross-module, and the symbol itself will be rebased, it cannot serve as
a constant initializer (the value is not known until runtime). However,
using a function pointer is permissible. The linker will materialize a
thunk for the function itself and cause the module to be force linked.
This also works on ELF and MachO as well. The overhead associated with
this is pretty minimal as the function itself has an empty body, and
flags will differentiate between a function and data symbol. The slight
penalty in size (on the order of 2-4 bytes) allows for the same pattern
to be used across all the targets.
- Expand operating system checks such that Glibc is properly
imported on Android.
- For tests that are unsupported on platforms that normally
do not support an Objective-C runtime, expand the unsupported
checks to include Android.
- Pass the `-sdk` parameter when invoking `%target-sil-opt`.
- Expect failures when testing semaphores, which are not included
in Android Bionic.
Autolinking was added to the frontend in 22912bc3b. It was disabled on
Linux in 198402dcf, and further constrained to be disabled on "linux-gnu"
in 83b4384fa. Since then, more flavors of Linux have become supported
by Swift: "linux-gnueabihf" in 4bf81e09d, and "freebsd" in f41b791d4.
Autolinking most likely does not work on any of these platforms, so
mark it as unsupported for now.
Other tests that only mark "linux-gnu" as unsupported do so for similar
reasons. Ensure unsupported tests for "linux-gnu" are also unsupported
on similar platforms.
As suggested by John. This results in the symbols being coalesced at static
link time into a single strong symbol in a built dylib. Fortunately we don't
care about the contents of these global symbols, so common linkage's
forced zero-initialization is fine. (Hey, C's tentative definitions are
useful for something after all.)
rdar://problem/20072051
Swift SVN r25804
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
Refuse to load a module if it was compiled for a different architecture or
OS, or if its minimum deployment target is newer than the current target.
Additionally, provide the target triple as part of pre-loading validation
for clients who care (like LLDB).
Part of rdar://problem/17670778
Swift SVN r24469
