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.
Use the Windows API `UnDecorateSymbolName` rather than `__cxa_demangle`
to undecorate the C++ symbols. `__cxa_demangle` is only available in
the itanium ABI, not under MS ABI. This allows us to properly
undecorate symbols on Windows.
This function is only used when backtracing is enabled. Use a
preprocessor guard to avoid defining the function when not used. This
prevents a -Wunused-function warning. NFC.
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
On 32bit platforms there are 7 bits reserved for the unowned retain count. This
makes overflow a likely scenario. Implement overflow into the side table.
rdar://33495003
* Implements a debugger hook (breakpoint) API and data structure. This structure is passed to the debugger and describes extra information about a fatal error or a non-fatal warning, which should be logged as a runtime issue.
This debugger hook is then used from two places, which currently only log to stderr:
- Runtime exclusivity violations.
- Swift 3 implicit Obj-C entrypoints.
A subsequent LLDB support will be able to catch these callbacks and show the runtime issues in a better way than just logging them to stderr. When the debugger is not attached, this shouldn't have any effect.
* Revert "[strip -ST] Disable runtime stack trace dumping on Darwin when asserts are disabled."
This reverts commit 6bc28ff1c9.
* Bring back important fixes from the revert of 6bc28ff1c9.
* Change swift::swift_reportError to only print the backtrace in assert builds (swift::warning prints backtrace always).
This commit disables runtime stack trace dumping via dladdr on Darwin when
asserts are disabled.
This stack trace dumping was added as a way to improve the ability to debug the
compiler for compiler developers. This is all well and good but having such a
feature always enabled prevents us from reducing the size of the swift standard
library by eliminating the swift nlist.
rdar://31372220
Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
