In order to perform layout, the remote mirrors library needs to know
about the size, alignment and extra inhabitants of builtin types.
Ideally we would emit a reflection info section in libswiftRuntime.o,
but in the meantime just duplicate builtin type metadata for all
builtin types referenced from the current module instead.
In practice only the stdlib and a handful of overlays like the SIMD
overlay use builtin types, and only a few at a time.
Tested manually by running swift-reflection-tool on the standard
library -- I'll add automated tests by using -parse-stdlib to
reference Builtin types in a subsequent patch that adds more layout
logic.
NFC if -enable-reflection-metadata is off.
When creating a TypeRef from metadata, we have a parent pointer
handy, and construct the TypeRef directly, so there's no need
to mutate the TypeRef after the fact.
When demangling a TypeRef from a string, the mangling encodes
the parent module or type context, so we can set it when
constructing the TypeRef there too.
We will be handing pointers to typerefs over the SwiftRemoteMirrors C
API boundary, at which point it is unclear who will hold onto a shared
pointer. The useful lifetime of a typeref is tied to the
ReflectionContext for which they were created anyway so, when it goes
away, all of those typerefs can go away anyway.
We can't use LLVM's bump-pointer allocator here because we only build
the Support library for the host. As a compromise, stuff new typeref
pointers into a vector pool, where they will be taken down during
ReflectionContext's destructor.
We'll need to drill into nested structs to get their field typerefs and
so on, without metadata necessarily available. Decouple the lookup from
the address.
TODO: Cache associated type descriptors based on typeref or mangled
name.
- Read the Parent pointer out of Class/Value metadata and create
typerefs for them.
- Add Parent fields to NominalTypeRef and BoundGenericTypeRef.
- Add TypeRef::getSubstMap(), which creates a new generic argument
map after substitution has taken place on it. This is used to
continue to burrow into nested value types, where generic type
parameters may have a different index.
- Use a DenseMap as that generic argument map.
- Unconditionally key the generic argument map with (Depth, Index)
- Clean up ordering and presentation of Index and Depth. In the rest
of the compiler, Depth comes before Index.
Once an unsubstituted typeref for a field is built, we substitute
`GenericTypeParameterTypeRef`s with concrete ones built from the generic
arguments of concrete bound generic metadata.
During that process, if we run into a `DependentMemberTypeRef` (e.g.
something of type T.Index), we substitute the base (T) using the current
list of substitutions, and then resolve what `Index` is for the base
using the associated type metadata in the 'assocty' data section.
Nominal type descriptors use declared types for their mangled names,
so we need to use them when scanning the fieldmd section for a
matching record. This is fine because the descriptor can tell us
about the type's generics. Individual field records continue to use
the interface type.
Adds a rough sketch of what will be a test harness, currently only supported
on OS X:
- Launch a child process: an executable written in Swift
- Receive the child process's Mach port
- Receive reflection section addresses and the address of a heap instance
of interest
- Perform field type lookup on the instance remotely (TODO)
These likely don't have Swift type metadata but might be useful to
record or instantiate based on what kind of metadata is encountered for
the sake of memory tools.
- Don't depend on LLVM Support and swiftBasic as this will bring in
llvmSupport and other heavy dependencies, which we don't build for
non-host architectures right now anyway.
- Add a reader template that works with the same (albeit somewhat
clunky) interface in-process with the runtime and remotely, by having
the memory tool supply a function that will copy data from the remote
process.
- Add a Buffer type to abstract indirecting pointers in a remote address
space, which is handled by the memory reader.
- Start sketching out the C remote mirrors interface.
- Nearly done: TypeRefs and the mangled name decoder.
- Add the swift-reflection-test tool.
The field reflection pipeline is roughly:
- Decode type references
- Substitute generic parameters
- Calculate sizes and offsets
There is currently only one action in the tool, which will test the
*Decode* part of the pipeline: `dump-reflection-section`. This reads
the *swift3_reflect section from an object file and dumps the decoded
type references for all of the stored properties and enum cases in the
file.
- TODO: Write tests with various type arrangements to exercise the
decoder - there are likely some holes in the decoder still since the
AST mangler is quite rich in its kinds.
TODO: The next test mode, `dump-field-types`, will do the following:
1. Launch a swift executable with a canned stopping point
2. Get the address of a heap object instance of interest
3. Dump the fully substituted typerefs of all of the stored properties
or enum case payloads.
That test mode will be more involved since it will attach to another
process and need to read from its address space but will test the
entire out-of-process reflection pipeline in a controlled environment.
We can maybe take this test a step further, with an option or a new
test mode, that prints the entire heap reference graph rooted at that
object of interest, in order to test the ability to detect reference
cycles, for example.
