Gather 'round to hear tell of the saga of autolinking in incremental
mode.
In the beginning, there was Swift code, and there was Objective-C code.
To make one import bind two languages, a twinned Swift module named the same as an
Objective-C module could be imported as an overlay. But all was not
well, for an overlay could be created which had no Swift content, yet
required Swift symbols. And there was much wailing and gnashing of teeth
as loaders everywhere disregarded loading these content-less Swift
libraries.
So, a solution was found - a magical symbol _swift_FORCE_LOAD_$_<MODULE>
that forced the loaders to heed the dependency on a Swift library
regardless of its content. It was a constant with common linkage, and it
was good. But, along came COFF which needed to support autolinking but
had no support for such matters. It did, however, have support for
COMDAT sections into which we placed the symbol. Immediately, a darkness
fell across the land as the windows linker loudly proclaimed it had
discovered a contradiction: "_swift_FORCE_LOAD_$_<MODULE> cannot be
a constant!", it said, gratingly, "for this value requires rebasing."
Undeterred, we switched to a function instead, and the windows linker
happily added a level of indirection to its symbol resolution procedure
and all was right with the world.
But this definition was not all right. In order to support multiple
translation units emitting it, and to prevent the linker from dead
stripping it, Weak ODR linkage was used. Weak ODR linkage has the nasty
side effect of pessimizing load times since the dynamic linker must
assume that loading a later library could produce a more definitive
definition for the symbol.
A compromise was drawn up: To keep load times low, external linkage was
used. To keep the linker from complaining about multiple strong
definitions for the same symbol, the first translation unit in the
module was nominated to recieve the magic symbol. But one final problem
remained:
Incremental builds allow for files to be added or removed during the
build procedure. The placement of the symbol was therefore dependent
entirely upon the order of files passed at the command line. This was no
good, so a decree was set forth that using -autolink-force-load and
-incremental together was a criminal offense.
So we must compromise once more: Return to a symbol with common linkage,
but only on Mach-O targets. Preserve the existing COMDAT-friendly
approach everywhere else.
This concludes our tale.
rdar://77803299
The layouts of resilient value types shipped in the Swift 5 standard library
x and overlays will forever be frozen in time for backward deployment to old
Objective-C runtimes. This PR ensures that even if the layouts of these types
evolve in the future, binaries built to run on the old runtime will continue
to lay out class instances in a manner compatible with Swift 5.
Fixes <rdar://problem/45646886>.
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.
