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
