We scan the target's initial allocation pool, and all 16kB heap allocations. We check each pointer-aligned offset within those areas, and try to read it as Swift metadata and get a name from it. If that fails, quietly move on. It's very unlikely for some random memory to look enough like Swift metadata for this to produce a name, so this works very well to print the generic metadata instantiated in the remote process without requiring `SWIFT_DEBUG_ENABLE_METADATA_ALLOCATION_ITERATION`.
rdar://161120936
The metadata creation system detects cycles where metadata depends on other metadata which depends on the first one again and raises a fatal error if the cycle can't be fulfilled.
Some cycles can be fulfilled. The cycle may involve a requirement for a metadata state less than full transitive completeness which can be reached without resolving the entire cycle. We only want to raise a fatal error when we detect a cycle that can't be fulfilled.
Normally this happens because the cycle checking in `blockOnMetadataDependency` only sees a cycle when it can't be fulfilled. Metadata initialization is advanced as far as it can be at each stage, so a cycle that can be fulfilled will see a fulfilling state and won't generate the dependency in the first place, since we only generate dependencies that haven't yet been met.
However, when two threads race to create types in a cycle, we can end up with such a dependency, because the dependency may be generated before another thread fulfilled yet. The cycle checker doesn't account for this and incorrectly raises a fatal error in that case.
Fix this by checking the cyclic dependency against the metadata's current state. If we have a dependency that's already been fulfilled, then there isn't really a dependency cycle. In that case, don't raise a fatal error.
rdar://135036243
To facilitate back deployment, make use of the fact that the async bit
has up to now never been set for read and modify accessors and claim
that set bit to indicate that it is a callee-allocated coroutine. This
has the virtue of being completely back deployable because like async
function pointers coro function pointers must be auth'd and signed as
data.
Replace this direct use of the count in a table header as the upper
bound of a for loop with a range-based for loop over the range which was
being indexed into. That range was constructed using that count to
begin with.
Rather than pass a MethodOverrideDescriptor directly, instead pass the
fields from it that are needed by the callee. In preparation for adding
another caller which doesn't have a MethodOverrideDescriptor.
We have a few constructor functions that aren't wrapped in SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_BEGIN/SWIFT_ALLOWED_RUNTIME_GLOBAL_CTOR_END and which have started to produce warnings in a new clang version. Explicitly allow these constructors by adding those.
rdar://147703947
We need a store-release when putting a new page onto the metadata allocator so that other threads see the initialization. We also need to tell TSan about our memory barriers here, to avoid false positives in __swift_instantiateConcreteTypeFromMangledName when it reads from memory allocated here.
rdar://145778813
The `-Winvalid-offsetof` warning is valid in this case. `offsetof` is
being applied to types with a non-standard layout. The layout of this
type is undefined by the specification. There is no guarantee that the
type layout is uniform across all ABIs. It is not possible to portably
compute the offset statically, especially efficiently.
Sink this check into a unit test to avoid performing this test at
runtime. In order to do this in the standard library, we would need to
do this check through a global constructor.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
The way that we include COMPATIBILITY_OVERRIDE_INCLUDE_PATH freaks out the
syntax highlighting of editors like emacs. It causes the whole file to be
highlighted like it is part of the include string.
To work around this, this patch creates a separate file called
CompatibilityOverrideIncludePath.h that just includes
COMPATIBILITY_OVERRIDE_INCLUDE_PATH. So its syntax highlighting is borked, but
at least in the actual files that contain real code, the syntax highlighting is
restored.
rdar://137066879
An unmanaged property does not map to an operation in CVW, instead it will be copied like primitive values. When instantiating the layout string, we correctly do not emit an operation, but we compute the offset to the next field as if we did. This is causing the offset to be incorrect and subsequent operations to be executed on the wrong address, causing crashes or other misbehavior.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
Merge the three-stage operation originally designed for field vectors into a single unified loop that acts directly on the ivar offsets instead of using a faux field offset vector.
We really don’t need ‘em; we can just adjust the direct field offsets.
The runtime entry point currently uses a weird little hack that we will refactor away shortly.
When an @objc @implementation class requires the use of `ClassMetadataStrategy::Update` because some of its stored properties do not have fixed sizes, we adjust the direct field offsets during class realization by emitting a custom metadata update function which calls a new entry point in the Swift runtime. That entry point adjusts field offsets like `swift_updateClassMetadata2()`, but it only assumes that the class has Objective-C metadata, not Swift metadata.
This commit introduces an alternative mechanism which does the same thing without using any Swift-only metadata. It’s a rough implementation with important limitations:
• We’re currently using the field offset vector, which means that field offsets are being emitted into @objc @implementation classes; these will be removed.
• The new Swift runtime entry point duplicates a lot of `swift_updateClassMetadata2()`’s implementation; it will be refactored into something much smaller and more compact.
• Availability bounds for this feature have not yet been implemented.
Future commits in this PR will correct these issues.
The descriptor and arguments for prespecialized metadata will always be in the shared cache. Skip creating the mangling for any lookup involving pointers outside the shared cache, as an optimization.
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
When ObjC interop is enabled, we emit what we think will be the class's InstanceStart and InstanceSize based on what we know about the superclass. We then fix up those values at runtime if they don't match. The compiler will emit this data into read-only memory if it knows they will always match, and then the runtime avoids writing to these fields if they already contain the correct value.
However, the compiler aligns the InstanceStart, but instance size is not aligned. For example:
class Super<T> { var bool = true }
class Sub: Super<Int> { var obj: AnyObject? }
Super's InstanceSize is 17 (on 64-bit) but Sub's InstanceStart is 24. The compiler sees a fixed layout and emits Sub's rodata into constant memory. The runtime sees that 24 does not equal 17 and tries to update it, but we don't want it to.
Instead, only update InstanceStart if it's too small to accommodate the superclass's InstanceSize. If it's overlay large then we'll just leave it alone. The compiler underestimates InstanceStart when it doesn't know the superclass's size so this should only happen due to alignment.
rdar://123695998
This library uses GenericMetadataBuilder with a ReaderWriter that can read data and resolve pointers from MachO files, and emit a JSON representation of a dylib containing the built metadata.
We use LLVM's binary file readers to parse the MachO files and resolve fixups so we can follow pointers. This code is somewhat MachO specific, but could be generalized to other formats that LLVM supports.
rdar://116592577
Create a version of the metadata specialization code which is abstracted so that it can work in different contexts, such as building specialized metadata from dylibs on disk rather than from inside a running process.
The GenericMetadataBuilder class is templatized on a ReaderWriter. The ReaderWriter abstracts out everything that's different between in-process and external construction of this data. Instead of reading and writing pointers directly, the builder calls the ReaderWriter to resolve and write pointers. The ReaderWriter also handles symbol lookups and looking up other Swift types by name.
This is accompanied by a simple implementation of the ReaderWriter which works in-process. The abstracted calls to resolve and write pointers are implemented using standard pointer dereferencing.
A new SWIFT_DEBUG_VALIDATE_EXTERNAL_GENERIC_METADATA_BUILDER environment variable uses the in-process ReaderWriter to validate the builder by running it in parallel with the existing metadata builder code in the runtime. When enabled, the GenericMetadataBuilder is used to build a second copy of metadata built by the runtime, and the two are compared to ensure that they match. When this environment variable is not set, the new builder code is inactive.
The builder is incomplete, and this initial version only works on structs. Any unsupported type produces an error, and skips the validation.
rdar://116592420
For calloc, the variable denoting the of elements comes first,
then the variable denoting the size of each element. However, both
arguments are swapped when calling this function in many places in this codebase.
