IRGen: Always use symbolic references in mangled names (on Mach-O platforms) #27467
Conversation
… vm address. 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.
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
The CMemoryReader interface relies on a `GetStringLength` callback, which returns zero either if the address is invalid or if a valid zero-length string exists at the given address. We don't want to break ABI with RemoteMirror, but we can work around this by issuing a one-byte read at the address and confirming that a null terminator exists there.
- Ensure QuotedString prints characters as `char` and not as an integer-like `unsigned char` - Assert when trying to add a null child node to a Demangle::Node
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.
…tforms) Now that `swift-reflection-dump` correctly handles pointer values and unresolved cross-image references (for Mach-O, at least), we can safely unconditionally use symbolic references in runtime mangled names without regressing offline reflection support.
jckarter
force-pushed
the
symbolic-reference-all-the-things
branch
from
1a460e7 to
c39a2ae
Compare
|
@swift-ci Please test |
|
Build failed |
|
@swift-ci Please test Windows |
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
|
Build failed |
|
Build failed |
|
Expect any run-time perf changes from this? Better, worse, smaller code size? |
|
Code size is slightly smaller but not really notably so. Performance of demangling strings should be much better, and we’ll avoid warming up the type lookup cache and allocating a bunch of memory. I was going to experiment with using mangled names for all metadata accessed after this. |
|
To be on a fully equal footing with open-coded accessor functions, we'll also need a way to encode pointers to conformances used by the type directly in the mangled name too so we don't have to do a global lookup for the conformance, but that would need a new symbolic reference form, so we'd have to deployment-target-gate it. |
…ointer size 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.
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.
|
@swift-ci Please test |
|
@swift-ci Please test Windows |
|
Build failed |
|
Build failed |
|
@swift-ci Please test Windows |
|
@swift-ci Please clean test Windows |
|
@jrose-apple Aside from performance and code size, another benefit of this is that it should define away the issues we've been having with mangled names and static linking, since now mangled names will always contain real symbol references to the metadata objects they require to be instantiated at runtime. |
Wire up support in
swift-reflection-dumpto correctly handle pointer values and walk the binding table in Mach-O images to follow unresolved symbol references, so that we can safely unconditionally use symbolic references in runtime mangled names without regressing offline reflection support.