Refactor the logic so to have a single target to reference the
compatibility libraries for the host, and use that when needed.
The main driver for this change is supporting the cross-compilation of
x86-64 on Apple Silicon.
Supports rdar://90307965
When cross compiling we are forcing the usage of the resource directory from
the bootstrapping0 compiler to ensure we are picking up the stdlib from
the SDK.
As a result we need to ensure to have legacy layouts for all the
architectures in that folder.
Addresses rdar://98899578
This patch removes the implementation implementations and just calls the
original symbol without the fixes. This allows the library to build and
for binaries to link against it without breaking anything with missing
symbols.
This patch gets everything to the point of building the library, but it
doesn't run yet since I have missing symbols.
Unlike previous compatibility libraries and the concurrency
compatibility library, I'm organizing the headers a bit more. This is
because we're merging the two libraries into one. They share some common
header names, and while I could rename them for namespacing purposes,
it's easier to just use a directory structure for this.
The `include/Runtime` and corresponding `Runtime/` directories are for
backdeployed changes to the stdlib itself.
The `include/Concurrency` and corresponding `Concurrency/` directories
are for backdeployed changes to the concurrency runtimes.
Moved the compatibility deployment targets to the top level CMakeLists.
Without this, if we build without SWIFT_BUILD_STDLIB set, the threading
library doesn't see the correct values. This didn't affect local builds
when testing the original fix, but it does affect B&I.
rdar://96690200
The threading library is being pulled into the compatibility libraries,
but in order to do that we need to make sure it gets built with the
correct deployment target. (Which means we need a special version for
the compatibility libraries.)
rdar://96690200
There's no guarantee that e.g. pthread_key_t is an integral type. It could
be some kind of struct, or some other thing that isn't valid as a template
argument.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
There's no guarantee that e.g. pthread_key_t is an integral type. It could
be some kind of struct, or some other thing that isn't valid as a template
argument.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
In #40610 some options were moved into `StdlibOptions.cmake`, but that
file is only included from `stdlib/CMakeLists.txt` and
`cmake/modules/StandaloneOverlay.cmake`. However, if one does not build
neither the dynamic nor the static standard library, but enables
building the "toolchain extras" with
`SWIFT_BUILD_STDLIB_EXTRA_TOOLCHAIN_CONTENT` `stdlib/CMakeLists.txt`
will not be included, but `stdlib/toolchain/CMakeLists.txt` will, which
uses a value from `StandardOverlay.cmake` that will not be provided the
correct default value and will skip building most of what
`SWIFT_BUILD_STDLIB_EXTRA_TOOLCHAIN_CONTENT` used to do.
Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
When back-deploying, create global-actor-qualified function types via a
separate entrypoint
(`swift_getFunctionTypeMetadataGlobalActorBackDeploy`) in the
compatibility library, which checks whether it is running with a
new-enough runtime to use `swift_getFunctionTypeMetadataGlobalActor`.
Failing that, it calls into a separate copy of the implementation that
exists only in the back-deployed concurrency library.
Fixes rdar://79153988.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
Some notes:
1. Even though I refactored out AccessSet/Access from Exclusivity.cpp ->
ExclusivityPrivate.h, I left the actual implementations of insert/remove in
Exclusivity.cpp to allow for the most aggressive optimization for use in
Exclusivity.cpp without exposing a bunch of internal details to other parts of
the runtime. Smaller routines like getHead() and manipulating the linked list
directly I left as methods that can be used by other parts of the runtime. I am
going to use these methods to enable backwards deployment of exclusivity support
for concurrency.
2. I moved function replacements out of the Exclusivity header/cpp files since
it has nothing to do with Exclusivity beyond taking advantage of the TLS context
that we are already using.
In a back deployment scenario, this will provide a place where one could provide
function implementations that are not available in the relevant stdlib.
This is just setting up for future work and isn't doing anything interesting
beyond wiring it up/making sure that it is wired up correctly with tests.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
to use it.
ConcurrentReadableHashMap is lock-free for readers, with writers using a lock to
ensure mutual exclusion amongst each other. The intent is to eventually replace
all uses ConcurrentMap with ConcurrentReadableHashMap.
ConcurrentReadableHashMap provides for relatively quick lookups by using a hash
table. Rearders perform an atomic increment/decrement in order to inform writers
that there are active readers. The design attempts to minimize wasted memory by
storing the actual elements out-of-line, and having the table store indices into
a separate array of elements.
The protocol conformance cache now uses ConcurrentReadableHashMap, which
provides faster lookups and less memory use than the previous ConcurrentMap
implementation. The previous implementation caches
ProtocolConformanceDescriptors and extracts the WitnessTable after the cache
lookup. The new implementation directly caches the WitnessTable, removing an
extra step (potentially a quite slow one) from the fast path.
The previous implementation used a generational scheme to detect when negative
cache entries became obsolete due to new dynamic libraries being loaded, and
update them in place. The new implementation just clears the entire cache when
libraries are loaded, greatly simplifying the code and saving the memory needed
to track the current generation in each negative cache entry. This means we need
to re-cache all requested conformances after loading a dynamic library, but
loading libraries at runtime is rare and slow anyway.
rdar://problem/67268325
This just is using the standard formatting suggested by clang-format.
This fixes the issue with forward declarations being injected into the
search order.
