This also adds a function to demangle a symbol, and a way for the
backtracing code to report warning messages to the same place as
the main runtime.
I'd like to rename the _swift_isThunkFunction() SPI also, but we
can't do that until we've made the changes to the _Backtracing
library, so we'll do that there instead.
rdar://110261430
On Linux it seems that the linker objects, probably because of link order,
to the definition of `swift::threading::fatal()` being in both static
libraries. Fix by moving `swift::threading::fatal()` to its own file
in the main runtime as well as the Concurrency runtime.
Fixes#59444.
We shouldn't include <windows.h> implicitly from .cpp files, but should
do it directly so that we know it's there.
Also, if we're including <windows.h>, do it at the top of the file.
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
We shouldn't include <windows.h> implicitly from .cpp files, but should
do it directly so that we know it's there.
Also, if we're including <windows.h>, do it at the top of the file.
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
Moved the _gCRAnnotations declarations to their own object module,
which will help to avoid duplicate symbol problems (at least with .a
files).
Also tweaked things to make it so that the demangler and runtime
versions of the message setting code will interoperate (and so that
they'll interoperate better with other implementations that might
creep in from somewhere, like the one in LLVMSupport).
rdar://91095592
The demangling library can't use the error handling from the main runtime
because it isn't always linked with it. However, it's useful to have
some error handling, and in particular to be able to get data into the
crash logs.
This is complicated because of the way the demangling library gets used,
the upshot of which is that I've had to add a second object library just
for libswiftCore's use, so that the demangler will use the runtime's
error handling functions when present, and fall back on its own when
they aren't.
rdar://89139049
Replace the `static std::mutex` with Swift's `StaticMutex` so that we
avoid triggering an error due to an exit time destructor. Repairs the
build after #38562.
Rather than using the forward declaration for the LLVMSupport types,
expect to be able to use the full declaration. Because these are
references in the implementation, there is no reason to use a forward
declaration as the full types need to be declared for use. The LLVM
headers will provide the declaration and definition for the types. This
is motivated by the desire to ensure that the LLVMSupport symbols are
properly namespaced to avoid ODR violations in the runtime.
This replaces `LLVM_LIBRARY_VISIBILITY` with `SWIFT_LIBRARY_VISIBILTIY`
througout the runtime. The purpose of this attribution is unclear -
building with `-fvisibility=hidden` would accomplish this. This is an
entirely mechanical change replacing the macro with the Swift namespaced
variant instead.
In Errors.cpp, PRIxPTR is used in a format string:
constexpr const char *format = "%-4u %-34s 0x%0.16" PRIxPTR " %s + %td\n";
This fails to build because of upstream changes in STLExtras:
049043b598 (diff-43fc25e3af55e1ae97f17ef051d68aa4)
This patch merely adds the include for the needed PRIxPTR define.
(cherry picked from commit 0529fbedca)
Android doesn't support the GNU backtrace call, but unwind.h is there to
help. The code is a little bit more complicated than a simple backtrace
call, but it is just a callback and the context struct.
Sadly, it seems that -funwind-tables is needed in every piece of code
that the backtrace needs to traverse, which means that at least the
runtime and the stubs need -funwind-tables. However, the flag has been
enabled for all targets (only on Android), just in case some other code
ends up being in the stack. This might only be necessary for ARM
targets, but currently we only build ARM targets in Android. The Swift
parts of the stack seems to have unwind information and can be unwind.
Another problem at the moment is the symbols from the executable are
normally missing. To get symbol names two things need to happen: the
symbol has to be public (so it is an exported symbol, and not just a
local symbol that dladdr seems to not provide the name), and the linker
has to be invoked with -export-dynamic. Without those two pieces, the
addresses are returned (and match the binary just fine), but no names
are printed.
We would not previously symbolicate the stack trace and as a result
would not display the stack trace. Add symbolication support to the
runtime to actually make use of the captured stack trace. This allows
us to get a stack trace when the standard library or swift code reports
a fatal error.
Describe the consequences of missing metadata instead of just posting a scary
message about a bug. Furthermore, since these warnings tend to show up in
playgrounds, and probably aren't relevant to the user of a playground, suppress
them when running in a playground. rdar://problem/44642942
LLVM r334283 changed StringRef::split(char) to be implemented using
StringRef::split(StringRef), which is not defined inline. Because Swift
uses StringRef without linking LLVM's libSupport.a, we can only use
functions that are defined inline in the headers. Swift currently only
builds LLVM for the host, so we cannot link libSupport.a without building
it for every target, which would be a big change. Instead, this changes
a few places in Swift to avoid using those split and rsplit functions.
rdar://problem/41029268
* Check for overflow in incrementWeak().
This mirrors what is currently done for unowned reference counts, where overflowing the side table field produces a fatal error. Without this, the count silently wrapped from 2^31-1 to 0, which then caused breakage when the balancing releases happened (possibly including use-after-free bugs).
* Fix the implementation of RefCounts::getWeakCount().
The previous implementation was only appropriate for heap objects, but not side tables. This resulted in the weak count always returning 0 or 1. This change specializes the implementation for the two different cases and returns the correct count for side tables.
* Test large weak retain counts.
This tests the largest allowed weak retain count, as well as the overflow check when that count is exceeded.
