When iterating over linked lists in the target process, bugs or corrupt data might cause us to enter an infinite loop. Limit these loops to a fixed number of iterations so that we fail more gracefully. These limits should be set to a level that no healthy program will approach.
Report Slab's Next pointer as a separate chunk in asyncTaskSlabAllocations. This lets tools see it as a pointer and see the connection to the next slab.
rdar://91289920
The immediate use case is only concretely-constrained existential
types, which could use a much simpler representation, but I've
future-proofed the representation as much as I can; thus, the
requirement signature can have arbitrary parameters and
requirements, and the type can have an arbitrary type as the
sub-expression. The latter is also necessary for existential
metatypes.
The chief implementation complexity here is that we must be able
to agree on the identity of an existential type that might be
produced by substitution. Thus, for example, `any P<T>` when
`T == Int` must resolve to the same type metadata as
`any P<Int>`. To handle this, we identify the "shape" of the
existential type, consisting of those parts which cannot possibly
be the result of substitution, and then abstract the substitutable
"holes" as an application of a generalization signature. That
algorithm will come in a later patch; this patch just represents
it.
Uniquing existential shapes from the requirements would be quite
complex because of all the symbolic mangled names they use.
This is particularly true because it's not reasonable to require
translation units to agree about what portions they mangle vs.
reference symbolically. Instead, we expect the compiler to do
a cryptographic hash of a mangling of the shape, then use that
as the unique key identifying the shape.
This is just the core representation and runtime interface; other
parts of the runtime, such as dynamic casting and demangling
support, will come later.
When possible, decode the DrainLock/ExecutionLock fields of tasks and actors in concurrency runtimes built with priority escalation, and show the corresponding thread info in swift-inspect output.
We weren't properly decoding actor flags previously, so fix that up as well and have Remote Mirror split them out into separate fields so clients don't have to. We were missing the Job Storage field from the definition of DefaultActorImpl in RuntimeInternals.h, fix that so we actually read the right data.
rdar://88598003
Have RemoteMirror internally decode these flags fields and return them as separate fields in the task/actor info. Handle the structures both with and without task escalation support.
Also show when a task is the current task on a thread in swift-inspect's task listing.
rdar://88598003
This adds a new reflection record type carrying spare bit information for multi-payload enums.
The compiler includes this for any type that might need it in order to accurately reflect the contents of the enum. The RemoteMirror library will use this if present to determine how to project the contents of the enum. If not present (for example, in older binaries), the RemoteMirror library falls back on an internal calculation of the spare bitmask.
A few notes:
* The internal calculation is not perfect. In particular, it does not support MPEs that contain other enums (e.g., optionals). It should accurately refuse to project any MPE that it does not correctly support.
* The new reflection field is designed to be expandable; this might someday avoid the need for a new section.
Resolves rdar://61158214
Adjust the iteration of the conformance table to match the current data structure layout.
`MapData` is a view into the `ConformanceState`:
~~~
[+0x00] Cache [Type: swift::ConcurrentReadableHashMap<ConformaanceCacheEntry, swift::StaticMutex>]
[+0x28] SectionsToScan [Type: swift::ConcurrentReadableArray<ConformanceSection>]
[+0x50] scanSectionsBackwards [Type: bool]
~~~
`Cache` itself is a structure:
~~~
[+0x00] ReaderCount [Type: std::atomic<uint32_t>]
[+0x04] ElementCount [Type: std::atomic<uint32_t>]
[+0x08] Elements [Type: std::atomic<swift::ConcurrentReadableHashMap<ConformanceCacheEntry, swift::staticMutex>::ElementStorage *>]
~~~
The `ElementStorage` backing `Elements` actually looks like:
~~~
[+0x00] Capacity [Type: uint32_t]
[+0x08] Elem [Typwe: ConformanceCacheEntry]
~~~
The `Capacity` field will be pointer aligned (a previous change has changed this
to be explicitly pointer sized bit-sliced). However, we would previously fail
to accomodate the `Capacity` field, and read the contents shifted by the size of
`Capacity`. This repairs the iteration off the `ConformanceCache`.
This removes the compatibility code (which seems suspect) for the runtime datastructures. Identified through Windows, this path will potentially misread the field and treat a pair of `uint32_t` as a pointer, which may succeed any way.
Most of the new inspection logic is in Remote Mirror. New code in swift-inspect calls the new Remote Mirror functions and formats the resulting information for display.
Specific Remote Mirror changes:
* Add a call to check if a given metadata is an actor.
* Add calls to get information about actors and tasks.
* Add a `readObj` call to MemoryReader that combines the read and the cast, greatly simplifying code chasing pointers in the remote process.
* Add a generalized facility to the C shims that can allocate a temporary object that remains valid until at least the next call, which is used to return various temporary arrays from the new calls. Remove the existing `lastString` and `lastChunks` member variables in favor of this new facility.
Swift-inspect changes:
* Add a new dump-concurrency command.
* Add a new `ConcurrencyDumper.swift` file with the implementation. The dumper needs to do some additional work with the results from Remote Mirror to build up the task tree and this keeps it all organized.
* Extend `Inspector` to query the target's threads and fetch each thread's current task.
Concurrency runtime changes:
* Add `_swift_concurrency_debug` variables pointing to the various future adapters. Remote Mirror uses these to provide a better view of a tasks's resume pointer.
rdar://85231338
The calculation failed to account for padding after the slab struct itself. We already account for this padding in HeaderSize, so use that instead of the raw struct size.
rdar://87607280
We remove the existing `swift_reflection_iterateAsyncTaskAllocations` API that attempts to provide all necessary information about a tasks's allocations starting from the task. Instead, we split it into two pieces: `swift_reflection_asyncTaskSlabPointer` to get the first slab for a task, and `+swift_reflection_asyncTaskSlabAllocations` to get the allocations in a slab, and a pointer to the next slab.
We also add a dummy metadata pointer to the beginning of each slab. This allows tools to identify slab allocations on the heap without needing to locate every single async task object. They can then use `swift_reflection_asyncTaskSlabAllocations` on such allocations to find out about the contents.
rdar://82549631
On Windows, std::max_align_t is only 8-byte aligned, but Swift assumes 16-byte alignment. MaximumAlignment is our notion of the maximum alignment of a type, so use that instead.
We remove the existing `swift_reflection_iterateAsyncTaskAllocations` API that attempts to provide all necessary information about a tasks's allocations starting from the task. Instead, we split it into two pieces: `swift_reflection_asyncTaskSlabPointer` to get the first slab for a task, and `+swift_reflection_asyncTaskSlabAllocations` to get the allocations in a slab, and a pointer to the next slab.
We also add a dummy metadata pointer to the beginning of each slab. This allows tools to identify slab allocations on the heap without needing to locate every single async task object. They can then use `swift_reflection_asyncTaskSlabAllocations` on such allocations to find out about the contents.
rdar://82549631
Fix the declaration of AsyncTask and add a test for iterateAsyncTaskAllocations. Reflection's declaration of AsyncTask had fallen out of sync with the real thing. The test that was supposed to catch this was never actually committed, oops.
Add a swift_reflection_libraryVersion variable to Remote Mirror to indicate the presence of this fix. In the future, the value can be incremented to signal the presence of other changes that can't otherwise be detected.
rdar://80035307
Implement a version of addImage that takes in a closure responsible
for finding the sections of interest. This allows for the registration
of metadata even in situations where the object file is not complete
(for example, when generated by the JIT).
This will allow the heap tool to work out which binary a dynamically allocated
class comes from, by looking up its nominal type descriptor address and then
seeing which binary contains that.
Fixes rdar://65742351.
Implement a version of projectExistential tailored for LLDB. There are 2
differences when projecting existentials for LLDB:
1 - When it comes to existentials, LLDB stores the address of the error
pointer, which must be dereferenced.
2 - When the existential wraps a class type, LLDB expects the address
returned is the class instance itself and not the address of the
reference.
This patch also adapts the swift reflection test machinery to test
projectExistentialAndUnwrapClass as well. This is done by exposing
the new functionality from swift reflection test. It is tested in
existentials.swift, and ensures that the typeref information is
exactly the same as what is expected from projectExistential,
except the out address.
(cherry picked from commit 55e971e06750c3ba29722d558cc5400298f6bdaf)
This changes how ReflectionContext reads machO reflection sections by reading them individually instead of as one big memory block spanning from the first to the last section (and including whatever else is in between). This change will enable an optimization on LLDB's side where, if we're reading read-only data, we read from the file-cache instead of the child process, which should speed up debugging when working with remote processes.
We found crashes deep in TypeRefBuilder that could traced back to a likely
nullptr RemoteRef<> section address. It is very plausible that this is
connected to a failed MemoryReader::getBytes() call, which can fail but
isn't checked.
This patch adds missing error checks to every call to readBytes().
rdar://74445486
(cherry picked from commit 714cefbba4)
swift::reflection::TypeInfo for (Clang-)imported non-Objective-C types. This is
needed to reflect on the size mixed Swift / Clang types, when no type metadata
is available for the C types.
This is a necessary ingredient for the TypeRef-based Swift context in
LLDB. Because we do not have reflection metadata for pure C types in Swift,
reflection cannot compute TypeInfo for NominalTypeRefs for those types. By
providing this callback, LLDB can supply this information for DWARF, and
reflection can compute TypeInfos for mixed Swift/C types.
to use it.
ConcurrentReadableHashMap is lock-free for readers, with writers using a lock to
ensure mutual exclusion amongst each other. The intent is to eventually replace
all uses ConcurrentMap with ConcurrentReadableHashMap.
ConcurrentReadableHashMap provides for relatively quick lookups by using a hash
table. Rearders perform an atomic increment/decrement in order to inform writers
that there are active readers. The design attempts to minimize wasted memory by
storing the actual elements out-of-line, and having the table store indices into
a separate array of elements.
The protocol conformance cache now uses ConcurrentReadableHashMap, which
provides faster lookups and less memory use than the previous ConcurrentMap
implementation. The previous implementation caches
ProtocolConformanceDescriptors and extracts the WitnessTable after the cache
lookup. The new implementation directly caches the WitnessTable, removing an
extra step (potentially a quite slow one) from the fast path.
The previous implementation used a generational scheme to detect when negative
cache entries became obsolete due to new dynamic libraries being loaded, and
update them in place. The new implementation just clears the entire cache when
libraries are loaded, greatly simplifying the code and saving the memory needed
to track the current generation in each negative cache entry. This means we need
to re-cache all requested conformances after loading a dynamic library, but
loading libraries at runtime is rare and slow anyway.
rdar://problem/67268325
