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.
Rather than build multiple copies of LLVMSupport (4x!) build it one and
merge it into the various targets. This would ideally not be needed to
be named explicitly everywhere, but that requires using `add_library`
rather than `add_swift_target_library`.
Reduce LLVMSupport to the subset required for the runtime. This reduces
the TCB and the overheads of the runtime. The inline namespace's
preservation ensures that ODR violations do not occur.
This adds a new copy of LLVMSupport into the runtime. This is the final
step before changing the inline namespace for the runtime support. This
will allow us to avoid the ODR violations from the header definitions of
LLVMSupport.
LLVMSupport forked at: 22492eead218ec91d349c8c50439880fbeacf2b7
Changes made to LLVMSupport from that revision:
process.inc forward declares `_beginthreadex` due to compilation issues due to custom flag handling
API changes required that we alter the `Deallocate` routine to account
for the alignment.
This is a temporary state, meant to simplify the process. We do not use
the entire LLVMSupport library and there is no value in keeping the
entire library. Subsequent commits will prune the library to the needs
for the runtime.
This code rearchitects and simplifies the projectEnumValue support by
introducing a new `TypeInfo` subclass for each kind of enum, including trivial,
no-payload, single-payload, and three different classes for multi-payload enums:
* "UnsupportedEnum" that we don't understand. This returns "don't know" answers for all requests in cases where the runtime lacks enough information to accurately handle a particular enum.
* MP Enums that only use a separate tag value. This includes generic enums and other dynamic layouts, as well as enums whose payloads have no spare bits.
* MP Enums that use spare bits, possibly in addition to a separate tag. This logic can only be used, of course, if we can in fact compute a spare bit mask that agrees with the compiler.
The final challenge is to choose one of the above three handlings for every MPE. Currently, we do not have an accurate source of information for the spare bit mask, so we never choose the third option above. We use the second option for dynamic MPE layouts (including generics) and the first for everything else.
TODO: Once we can arrange for the compiler to expose spare bit mask data, we'll be able to use that to drive more MPE cases.
Teach RemoteMirror how to project enum values
This adds two new functions to the SwiftRemoteMirror
facility that support inspecting enum values.
Currently, these support non-payload enums and
single-payload enums, including nested enums and
payloads with struct, tuple, and reference payloads.
In particular, it handles nested `Optional` types.
TODO: Multi-payload enums use different strategies for
encoding the cases that aren't yet supported by this
code.
Note: This relies on information from dataLayoutQuery
to correctly decode invalid pointer values that are used
to encode enums. Existing clients will need to augment
their DLQ functions before using these new APIs.
Resolves rdar://59961527
```
/// Projects the value of an enum.
///
/// Takes the address and typeref for an enum and determines the
/// index of the currently-selected case within the enum.
///
/// Returns true iff the enum case could be successfully determined.
/// In particular, note that this code may fail for valid in-memory data
/// if the compiler is using a strategy we do not yet understand.
SWIFT_REMOTE_MIRROR_LINKAGE
int swift_reflection_projectEnumValue(SwiftReflectionContextRef ContextRef,
swift_addr_t EnumAddress,
swift_typeref_t EnumTypeRef,
uint64_t *CaseIndex);
/// Finds information about a particular enum case.
///
/// Given an enum typeref and index of a case, returns:
/// * Typeref of the associated payload or zero if there is no payload
/// * Name of the case if known.
///
/// The Name points to a freshly-allocated C string on the heap. You
/// are responsible for freeing the string (via `free()`) when you are finished.
SWIFT_REMOTE_MIRROR_LINKAGE
int swift_reflection_getEnumCaseTypeRef(SwiftReflectionContextRef ContextRef,
swift_typeref_t EnumTypeRef,
unsigned CaseIndex,
char **CaseName,
swift_typeref_t *PayloadTypeRef);
```
Co-authored-by: Mike Ash <mikeash@apple.com>
To allow more pervasive use of TypeRefs in LLDB, we need a way to build mangled
names from TypeRef pointers to allow round-tripping between TypeRefs and AST
types. The goal is to experiment with making lldb::CompilerType backed by
TypeRefs instead of AST types.
<rdar://problem/55412775>
Separate out the host build of SwiftRemoteMirror from the "target" build
(the host for the standard library may be different from the host for
the compiler). Restructure the build to ensure that we use the correct
compiler for building the SwiftRemoteMirror for the host. This fixes a
build issue when building for Linux AArch64.
Instead of passing around raw local pointers and references, and spreading
tricky offset arithmetic around with the Local/RemoteAddress fields in
ReflectionInfo, have the TypeRefBuilder code use RemoteRefs everywhere,
which keep the remote/local mapping together in one unit and provide
centralized API for this logic.
This doesn't yet change how code uses the RemoteRef address data to
follow pointers across objects, for things like reading type refs, but
that should be much easier to do after this lands.
These are now always zero, because memory readers handle virtual address mapping.
The `swift_reflection_info_t` structure used by the C RemoteMirror API keeps
its offset fields because it's supposed to be a stable API, but we now assert that
the values are always zero.
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
Also have swift-reflection-test check if the symbol exists. This allows swift-reflection-test to work with older Remote Mirror dylibs that don't have it.
rdar://problem/50030805
This symbol is meant to be exposed to users of the SwiftRemoteMirror
library which requires that it is explicitly marked with the appropriate
DLL storage on Windows. This should repair the Windows build.
Recent Swift uses 2 as the is-Swift bit when running on newer versions, and 1 on older versions. Since it's difficult or impossible to know what we'll be running on at build time, make the selection at runtime.
We were previously treating all the builds as shared, which is not the
case for the host library build of SwiftRemoteMirror. The warnings were
lost in the interminable spew from the build which is now fixed and this
stands out.
Seems that the change in the two variables was spilling into the other
target of the file, but returning it back to the original values seems
to avoid that issue.
This should unbreak the Android CI build. In it, the Linux static
library was changing to the host compiler, and that compiler was being
used for the Android runtime library, which would have never compile
that way (since the host compiler in CI is an old-ish Clang without the
necessary argument).
This adds an explicit version of the SwiftRemoteMirror library for use
in the tools that comprise the toolchain. This is a separate build from
the target specific builds of the library even though we may be building
the runtime for the (same) host.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
* Change the RemoteMirror API to have extensible data layout callback
* Use DLQ_Get prefix on DataLayoutQueryType enum values
* Simplify MemoryReaderImpl and synthesize minimalDataLayoutQueryFunction
Mark the public interfaces with the appropriate visibility/dll storage.
This fixes an issue with the Windows build which keeps the
SwiftRemoteMirror.dll out of date constantly as no import library is
created. That occurs due to the fact that the library does not export
any interfaces.
Take the opportunity to move the public interfaces to protected
visibility on ELF.
