Return a 32-bit or 64-bit ptrauth mask appropriate for the target. This should correct a crash when a 64-bit swift-reflection-dump executable was used to inspect a 32-bit target binary.
Resolves rdar://60966825
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>
Collect the relative and symbol relocations from ELF images in order to resolve pointer values
read from disk. This allows us to enable symbolic-referencing-all-the-things for ELF platforms.
My previous attempt doesn't work well for 32-bit targets; 32-bit memory readers
reasonably assume that they only get 32-bit RemoteAddress values. When working
with multiple images, instead pack them all into a contiguous subset of the
address space.
Necessary to make sure we read pointers as the right size, and use the correct object layouts
when using swift-reflection-dump for cross-platform dumps.
When resolving a pointer value in a Mach-O image, look through the binding list
to see if a symbol address will be added at a given location, and return
an unresolved `RemoteAbsolutePointer` with the symbol name if so.
As the base of the "remote" address space ObjectMemoryReader presents for an image, use the
image's own preferred VM address mappings. If there are multiple images loaded, differentiate
them by using the top 16 bits of the remote address space as an index into the array of images.
This should make it so that absolute pointers in the file Just Work without sliding in most
cases; we'd only need to mix in the image index in order to have a value that is also a valid
remote address.
Instead of copying the entire object file and moving around its sections to make an approximate
representation of its mapped state, use the memory-mapped buffer from `llvm::ObjectFile`, and
deal with non-contiguous logical mappings entirely in readBytes.
NOTE: I used YAMLIO to simplify dumping this information which required me to
use llvm::outs() instead of std::cout like the rest of libReflection. We really
should remove std::cout from libReflection (iostream is a smell we try to avoid
generally). As a result, there is a little bit of finagling in the commit to
work around flushing issues with respect to use llvm::outs(), std::cout... but
it isn't too bad overall.
Updated uses of object::SectionRef::getContents() since it now returns
an Expected<StringRef> instead of modifying the one it's passed.
See also: git-svn-id:
https://llvm.org/svn/llvm-project/llvm/trunk@360892
91177308-0d34-0410-b5e6-96231b3b80d8
Previously when ReflectionContext was parsing the image of a binary
(for ELF or COFF) it was making some incorrect assumptions about the location
of sections in the memory of a remote process. In particular, it was using the offsets
rather than the virtual addresses and it was incorrectly calculating the references (relative pointers)
inside the metadata. In this diff we address these issues and adjust swift-reflection-dump
(used in tests) to emulate the runtime behavior more closely.
This diff has been extensively tested, the reflection tests are green on OSX and Linux,
on Windows it fixes 2 new tests:
Reflection/typeref_decoding.swift
stdlib/ReflectionHashing.swift
So now (with some minor fixes to the lit testsing infrastructure) the following reflection
tests pass:
Reflection/box_descriptors.sil
Reflection/capture_descriptors.sil
Reflection/typeref_decoding.swift
stdlib/ReflectionHashing.swift
cl is unable to differentiate between the `swift::ReflectionContext` and
`swift::reflection::ReflectionContext`. Use the elaborated typename to
uniquely identify the type. This allows us to build
`swift-reflection-dump` with cl again.
* Change the RemoteMirror API to have extensible data layout callback
* Use DLQ_Get prefix on DataLayoutQueryType enum values
* Simplify MemoryReaderImpl and synthesize minimalDataLayoutQueryFunction
Tiny start-up time optimization noticed while looking at how we do
PrettyStackTraceProgram. Also add PrettyStackTraceProgram to a few
more of our testing tools, via the new PROGRAM_START macro.
This makes resolving mangled names to nominal types in the same module more efficient, and for eventual secrecy improvements, also allows types in the same module to be referenced from mangled typerefs without encoding any source-level name information about them.
The remote reflection library has a fantastic utility class, TypeDecoder,
to take a mangled type and form an abstract type from it. Move this facility
into the Demangling library so other clients can use it.
ELF is segment mapped, where the segment which contains a particular
section may be mapped to an address which does not correspond to the
address on disk. Since the reflection dumper does not use the loader to
load the image into memory, we must manually account for any section
offsets. Calculate this value when we query the mmap'ed image and wire
it through to the relative direct pointer accesses.
When switching to the linker table approach for the ELF metadata
introspection, this was uncovered as the segment containing the orphaned
sections was coalesced into a separate PT_LOAD header which had a non-0
offset for the mapping.
Restructure the ELF handling to be completely agnostic to the OS.
Rather than usng the loader to query the section information, use the
linker to construct linker tables and synthetic markers for the
beginning and of the table. Save off the values of these pointers and
pass them along through the constructor to the runtime for registration.
This removes the need for the begin/end objects. Remove the special
construction of the begin/end objects through the special assembly
constructs, preferring to do this in C with a bit of inline assembly to
ensure that the section is always allocated.
Remove the special handling for the various targets, the empty object
file can be linked on all the targets.
The new object file has no requirements on the ordering. It needs to
simply be injected into the link.
Name the replacement file `swiftrt.o` mirroring `crt.o` from libc. Merge
the constructor and the definition into a single object file.
This approach is generally more portable, overall simpler to implement,
and more robust.
Thanks to Orlando Bassotto for help analyzing some of the odd behaviours
when switching over.
Previously it was part of swiftBasic.
The demangler library does not depend on llvm (except some header-only utilities like StringRef). Putting it into its own library makes sure that no llvm stuff will be linked into clients which use the demangler library.
This change also contains other refactoring, like moving demangler code into different files. This makes it easier to remove the old demangler from the runtime library when we switch to the new symbol mangling.
Also in this commit: remove some unused API functions from the demangler Context.
fixes rdar://problem/30503344
This makes the demangler about 10 times faster.
It also changes the lifetimes of nodes. Previously nodes were reference-counted.
Now the returned demangle node-tree is owned by the Demangler class and it’s lifetime ends with the lifetime of the Demangler.
Therefore the old (and already deprecated) global functions demangleSymbolAsNode and demangleTypeAsNode are no longer available.
Another change is that the demangling for reflection now only supports the new mangling (which should be no problem because
we are generating only new mangled names for reflection).
