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
This patch adds a new SymbolicExtendedExistentialTypeRef kind, and
wires it up in TypeDecoder, TypeRefBuilder, TypeLowering, and
ASTDemangler.
This is tested indirectly via the matching LLDB commit.
Add an extra opaque field to AddressSpace, which can be used by clients
of RemoteInspection to distinguish between different address spaces.
LLDB employs an optimization where it reads memory from files instead of
the running process whenever it can to speed up memory reads (these can
be slow when debugging something over a network). To do this, it needs
to keep track whether an address originated from a process or a file. It
currently distinguishes addresses by setting an unused high bit on the
address, but because of pointer authentication this is not a reliable
solution. In order to keep this optimization working, this patch adds an
extra opaque AddressSpace field to RemoteAddress, which LLDB can use on
its own implementation of MemoryReader to distinguish between addresses.
This patch is NFC for the other RemoteInspection clients, as it adds
extra information to RemoteAddress, which is entirely optional and if
unused should not change the behavior of the library.
Although this patch is quite big the changes are largely mechanical,
replacing threading StoredPointer with RemoteAddress.
rdar://148361743
Reflection metadata lookup failures are notoriously difficult to debug
because there is no error handling in TypeLowering outside of
compile-time #ifdef'd fprintf(stderr) calls. The nicest thing to do
would be to adopt llvm::Expected<> but TypeLowering is also included
in the standard library, which only has access to a tiny subset of the
LLVM Support library. This patch adds a place to store a pointer to
the first encountered error, which can then be converted to an
llvm::Error at the API level.
Fixes the immediate problem, but the presence of demangling code in the
runtime means that we'll need a follow-up to fix the compiler so that it
doesn't try to use the demangler to materialize metadata for function types
that have both isolation and a sending result.
rdar://142443925
To determine the correct enum layout, we first count various
categories of cases. Before, we counted indirect generic cases as
"generic", but regular "generic" cases can't export spare bits.
Change this to count "indirect" cases as a separate category.
In particular, this ensures that fully-indirect enums use
spare bits from the pointers even when some or all of the cases
are generic.
Resolves rdar://133890406
The first word in a class existential is the class pointer itself.
This pointer exposes spare bits differently depending
on the platform, which becomes apparent when you try to reflect
an Optional carrying such an MPE.
Add new test cases and some logic to zero out the first
word of spare bit information only on platforms with 8-byte pointers.
Class existentials expose spare bits from all of the pointers, not just the first one.
Due to a bad bug here, we were properly exposing spare bits from the first pointer,
but then claiming that all bits of subsequent pointers were spare.
This accidentally resulted in the correct operation on 64-bit targets
(it picked the highest-order spare bit, which happened to be spare
in both the broken mask and the correct mask). But on 32-bit targets,
this exposed the high-order bits of pointers, which is incorrect.
Expand the test a bit while we're here as well.
Resolves rdar://132715829
This plugs a hole where we failed to recognize a CF type when it
appeared as the payload of an enum stored as a property. Curiously,
RemoteMirror is able to reflect this when the enum appears by itself,
just not when it's stored as a property.
The simplest fix is to hook into the TypeInfo calculation which
computes a TypeInfo (basically, the tree of fields) from a TypeRef
(basically, the name of the type, including generic context).
Specifically, we sometimes end up here with a "type alias" that
none of the lookup support seems to be able to handle. Fortunately,
these aliases demangle into a pretty predictable shape, so this
just pattern-matches the specific demangle tree shape to recognize
these as "type aliases in the `__C` module whose name starts with `CF`
and ends with `Ref`".
Resolves rdar://82465109
UnsafeContinuations can be stored in variables or properties,
so it's important for RemoteMirror to be able to at least minimally
recognize them.
This just treats an UnsafeContinuation as a refcounted pointer.
Which might be "good enough" for now.
Working towards rdar://110351406
The "generic depth" is used to match up generic type variables.
For example:
```
struct Foo<T> { // `T` at generic depth 0
struct Bar {
struct Baz<U> { // 'U' at generic depth 1
...
}}}
```
Note in the above that `Bar` is not counted in the
generic depth. The previous logic did count `Bar` in
the generic depth calculation, leading to mismatches
when trying to associate references to generic variables.
This adds a new test with cases like the above and of course
corrects the calculation.
Resolves rdar://127450037
This fills in a number of missing cases:
* MPEs with closure payloads
* MPEs with many non-payload cases
* MPEs with class existential payloads
* MPEs with existential metatype payloads
Resolves rdar://132270733
Resolves rdar://128705332
Out of an abundance of caution, we:
1. Left in parsing support for transferring but internally made it rely on the
internals of sending.
2. Added a warning to tell people that transferring was going to
be removed very soon.
Now that we have given people some time, remove support for parsing
transferring.
rdar://130253724
without relying on spare bit information in the reflection metadata
(which was added in #40906). As a result, we can remove the
code from #40906.
This is the first step in such removal. It removes the RemoteMirror
code for looking up such metadata. It leaves behind:
* Sufficient stubs for LLDB to continue to build. Once LLDB is updated, these stubs can be removed as well.
* The compiler code to emit such metadata. This allows new binaries to still reflect MPEs on older runtimes. This will need to be kept for a transitional period.
RemoteMirror gets called on lots of malformed type information,
due to memory corruption bugs or even clients that ask RemoteMirror
to decode a chunk of memory to test whether or not it might be
valid type data. In any case, we need to be a little cautious here.
In this case, I've chosen to ignore any enum whose in-memory size
(according to the metadata) is over 1 MiB. We can easily adjust
this limit up if experience shows there really are legitimate enums
this large in the wild.
If an Int type makes no sense (it has a nonsensical number
of extra inhabitants, for example), ignore it rather than
treating it as a non-Int type.
Rename `isIntType()` to `intTypeBitSize()` to better document
what this function actually returns.
MPE layout code to exclusively use the new code. The key observation: existing
reflection metadata seems to already provide enough information in all cases, so
we can abandon an earlier effort to add spare bitmask data.
Resolves rdar://129281368
No metadata is emitted for the builtin DefaultActorStorage type. Since
its layout is fixed, hardcode its definition in Remote Mirrors.
rdar://128032250
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
This adds a `getSpareBits` method to all the TypeInfo classes
that returns a suitable bitmask indicating the spare bits available
in values of this type. This gives us a way to recursively explore
the type tree and build up a full spare bit mask for an arbitrary type.
Happily, it appears we actually do have enough information to do this
calculation entirely from first principles, without requiring additional
reflection information. So once this is stable, we should remove my
earlier incomplete effort to publish spare bit mask info in the reflection
data, as that adds unnecessary metadata to every binary.
This doubtless still has plenty of holes, but seems sufficient
to handle a few basic enum types, including the stdlib DecodingError
which was used as an example to work out some key issues.
Even with `std::hex`, the `uint8_t` values are being printed as characters, not hex
values. This change casts the value to `int`, which results in the hex representation
being properly printed.
