Tweaked the comment in `Runtime/Config.h`.
Fixed a couple of incorrect ARM64 instruction mnemonics. This still needs
testing on ARM64 Windows.
Fixed an out-of-date comment in `swift-backtrace`.
Use a macro in `Backtrace.cpp` to guarantee we don't overrun the buffer,
and in the process simplify the code slightly.
rdar://101623384
`swift_slowAlloc()` and related functions assume that `malloc(0)` and `aligned_alloc(0)` return non-`NULL` pointers. The C standards allow implementations to return `NULL` when the allocation size is `0`.
This PR implements a check for `0` that instead allocates `1`. The cost of the check is negligible next to the cost of actually allocating, but we'll mark it `SWIFT_UNLIKELY` just in case.
Resolves rdar://169304909.
Hitting `D` when in the backtracer should do the same on Windows
that it does on macOS, namely launching `lldb` and attaching it to
the crashed program.
rdar://101623384
On-crash backtracing is basically there for 64-bit Windows. It
won't work on 32-bit because of a Swift compiler issue, and there
is a little more work to do yet, but it is now working!
rdar://101623384
This doesn't have a working symbolicator yet, but it does build and
it can obtain a basic backtrace.
It also doesn't include a working `swift-backtrace` program yet.
rdar://101623384
Replaces isKindOfClass with object_getClass to ensure 'other' is exactly a _SwiftValue box, not a subclass. This works because other has no subclasses/proxies.
Replace C++ implementation of swift_beginAccess and swift_endAccess with (almost) pure Swift implementation. Helpers remain in C++ for TLS, getting return addresses, and raising a fatal error on violations.
This change also moves the exclusivity access set head from the shared SwiftTLSContext structure to a dedicated TLS key. This improves performance, which is important for exclusivity checking. This is particularly the case where we can inline TLS access with a constant key, as on Darwin ARM64.
The code that bridges exclusivity tracking into Concurrency remains in C++. The new Swift implementation exposes a few helpers for it to use as a replacement for directly manipulating the C++ implementation.
rdar://161122309
We should expose the demangle functionality; It's been widely used by
calling into internal _swift_demangle and instead we should offer a real
API. It's also already used in the Runtime module already when forming
backtraces.
[Previous
discussions](https://forums.swift.org/t/demangle-function/25416/15)
happened between 2019 and 2024, and just never materialized in a
complete implementation and proposal.
Right now, even more tools are in need of this API, as we are building
continious profiling solutions etc, so it is a good time to revisit this
topic.
This PR is roughly based off @Azoy's
https://github.com/swiftlang/swift/pull/25314/files#diff-fd379a721cc9a1c9ef6486eae713e945da842b42170d4d069029a57334371eba
from 2019, however it brings it over to the new Runtime module which is
a great place to put this functionality - even Backtrace had to recently
reinvent calling the demangling infra in this module.
Pending SE review, [proposal
here](https://github.com/swiftlang/swift-evolution/pull/2989).
cc @azoy @al45tair
---------
Co-authored-by: Alastair Houghton <alastair@alastairs-place.net>
`[[no_unique_address]]` is a C++20 feature and we currently use C++17.
Guard this with `__clang__` and use the clang namespaced attribute which
is available. Additionally, since this feature is supported by MSVC as
well as an extension in earlier versions, use the MSVC scoped attribute
on MSVC.
If you added threads=all to the SWIFT_BACKTRACE settings, it actually prevented all threads from being shown. This fixes that.
Also, the multiple thread test should test for presence of multiple threads.
rdar://166532079
The `color=tty` setting was checking `stdout` to see if it was a TTY, but
we may be using `stderr`, in which case it's easy to end up with coloured
output in a file we're redirecting to. Fix it to check the selected
output instead.
rdar://164624364
Instead of copying the data and the type and witnesses separately, use the size in the value witness table and copy everything at once.
copyTypeInto assumed the type was an ordinary existential. When it was actually an extended existential, it would do an incorrect cast and read part of a pointer as the number of witness tables to copy. This would typically result in a large buffer overflow and crash. At this point we already know the type's size, so we can use that info directly rather than essentially recomputing it.
rdar://163980446
Add SWIFT_DEBUG_ENABLE_TASK_SLAB_ALLOCATOR, which is on by default. When turned off, async stack allocations call through to malloc/free. This allows memory debugging tools to be used on async stack allocations.
This is breaking embedded due to its use of weak definitions for embedded versions of the runtime functions. The presence of a weak export in libswiftCore allows any strong symbol in libswiftCore to override a weak symbol elsewhere. Remove while we work out how to reconcile the two.
rdar://163578646
This is currently disabled by default. Building the client library can be enabled with the CMake option SWIFT_BUILD_CLIENT_RETAIN_RELEASE, and using the library can be enabled with the flags -Xfrontend -enable-client-retain-release.
To improve retain/release performance, we build a static library containing optimized implementations of the fast paths of swift_retain, swift_release, and the corresponding bridgeObject functions. This avoids going through a stub to make a cross-library call.
IRGen gains awareness of these new functions and emits calls to them when the functionality is enabled and the target supports them. Two options are added to force use of them on or off: -enable-client-retain-release and -disable-client-retain-release. When enabled, the compiler auto-links the static library containing the implementations.
The new calls also use LLVM's preserve_most calling convention. Since retain/release doesn't need a large number of scratch registers, this is mostly harmless for the implementation, while allowing callers to improve code size and performance by spilling fewer registers around refcounting calls. (Experiments with an even more aggressive calling convention preserving x2 and up showed an insignificant savings in code size, so preserve_most seems to be a good middle ground.)
Since the implementations are embedded into client binaries, any change in the runtime's refcounting implementation needs to stay compatible with this new fast path implementation. This is ensured by having the implementation use a runtime-provided mask to check whether it can proceed into its fast path. The mask is provided as the address of the absolute symbol _swift_retainRelease_slowpath_mask_v1. If that mask ANDed with the object's current refcount field is non-zero, then we take the slow path. A future runtime that changes the refcounting implementation can adjust this mask to match, or set the mask to all 1s to disable the old embedded fast path entirely (as long as the new representation never uses 0 as a valid refcount field value).
As part of this work, the overall approach for bridgeObjectRetain is changed slightly. Previously, it would mask off the spare bits from the native pointer and then call through to swift_retain. This either lost the spare bits in the return value (when tail calling swift_retain) which is problematic since it's supposed to return its parameter, or it required pushing a stack frame which is inefficient. Now, swift_retain takes on the responsibility of masking off spare bits from the parameter and preserving them in the return value. This is a trivial addition to the fast path (just a quick mask and an extra register for saving the original value) and makes bridgeObjectRetain quite a bit more efficient when implemented correctly to return the exact value it was passed.
The runtime's implementations of swift_retain/release are now also marked as preserve_most so that they can be tail called from the client library. preserve_most is compatible with callers expecting the standard calling convention so this doesn't break any existing clients. Some ugly tricks were needed to prevent the compiler from creating unnecessary stack frames with the new calling convention. Avert your eyes.
To allow back deployment, the runtime now has aliases for these functions called swift_retain_preservemost and swift_release_preservemost. The client library brings weak definitions of these functions that save the extra registers and call through to swift_retain/release. This allows them to work correctly on older runtimes, with a small performance penalty, while still running at full speed on runtimes that have the new preservemost symbols.
Although this is only supported on Darwin at the moment, it shouldn't be too much work to adapt it to other ARM64 targets. We need to ensure the assembly plays nice with the other platforms' assemblers, and make sure the implementation is correct for the non-ObjC-interop case.
rdar://122595871
This PR replaces our use of `__dso_handle` and (indirectly) `dladdr()`
when figuring out the base address of loaded Swift images on ELF-based
platforms. Instead, we use `__ehdr_start` which refers to the start of
the image's ELF header (i.e. the start of the file) and is provided by
the compiler/linker for this purpose.
This pointer is consumed by `swift_addNewDSOImage()` and, later, by
Swift Testing when running tests, but is otherwise unused, so the less
work we do on it at runtime, the better.
A fallback path is present that, for images that do not contain
`__ehdr_start`, derives the address by calling `dladdr()` on the section
structure's address.
Resolves#84997.
