On Darwin, `RTLD_NEXT` doesn't do what we need it to here, with the
result that if `libswiftCore`'s TSan initializer gets found first,
then `libswift_Concurrency` won't have its initializer called at all,
in spite of us using `RTLD_NEXT` to find the next definition.
Fix this by centralising the initializer in `libswiftCore` instead.
rdar://110665213
* Use the longer name ThreadSanitizer rather than TSan for the new files.
* Don't implement `tsan::consume` at all for now.
* Do the `tsan::release` for `ulock_unlock()` at the head of the function,
not at the tail.
* Add a comment to test/Sanitizers/tsan/once.swift to explain the test a
little more clearly.
rdar://110665213
Move the TSan functionality from Concurrency into Threading. Use it
in the Linux `ulock` implementation so that TSan knows about `ulock`
and will tolerate the newer `swift_once` implementation that uses it.
rdar://110665213
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
The threading code is required by some of the compatibility modules,
but we weren't pulling it in unless we were building the standard library.
That breaks the build when the standard library build is disabled, so
explicitly include it.
rdar://90776105
Removing thread_get_main() means we don't need a static initializer on
Darwin, which means we can delete Darwin.cpp as well. We can also delete
Nothreads.cpp while we're about it, because there's nothing in that file.
rdar://90776105
When we static link against libswiftCore, we need it to contain the
actual object modules from the threading library (when it's dynamically
linked, the shared object will already contain those modules because it's
been linked against libswiftThreading), which means that the threading
library in the stdlib needs to be an OBJECT_LIBRARY rather than a STATIC
library (otherwise people will have to statically link against the
threading library as well, and that'll need to be installed, and we don't
want that).
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
Removing thread_get_main() means we don't need a static initializer on
Darwin, which means we can delete Darwin.cpp as well. We can also delete
Nothreads.cpp while we're about it, because there's nothing in that file.
rdar://90776105
When we static link against libswiftCore, we need it to contain the
actual object modules from the threading library (when it's dynamically
linked, the shared object will already contain those modules because it's
been linked against libswiftThreading), which means that the threading
library in the stdlib needs to be an OBJECT_LIBRARY rather than a STATIC
library (otherwise people will have to statically link against the
threading library as well, and that'll need to be installed, and we don't
want that).
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
