[DSC] Fix support for iOS 15 shared caches #7399
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
emesare
reviewed
Sep 14, 2025
| { | ||
| m_localSymbolsEntry = std::move(entry); | ||
| // Map the entire file into its own virtual memory space. | ||
| // This is necessary due to code that processes symbols being written in terms of a `VirtualMemory` |
There was a problem hiding this comment.
You can use the fileAccessor in place of the m_localSymbolsVM, since it is just that file mapped at zero and it does not exist inside the regular virtual memory.
Just a suggestion, nothing blocking
There was a problem hiding this comment.
As the comment mentions, this uses a VirtualMemory as SharedCacheMachOHeader::ReadSymbolTable requires one. Since it is also used to process symbol tables inside images, such as in macOS shared caches, it cannot be updated to work with a FileAccessor. Some additional refactoring would be required to remove that use of VirtualMemory.
Prior to macOS 13 / iOS 16, the base offset to use for relative direct selector references within Objective-C message lists was stored within the `__TEXT,__objc_opt_ro` section of /usr/lib/libobjc.A.dylib.
In some iOS 15 caches, the .symbols file's mapping has an address of 0. This would cause it to be returned by `SharedCache::GetEntryContaining` and loaded into the view. The .symbols file contains the local symbol tables for images in the shared cache. It is not intended to be mapped into the same address space as the rest of the shared cache. `SharedCache` now tracks the symbols cache entry separately from other entries. A dedicated `VirtualMemory` region is used when accessing the data it contains. This could be a `FileAccessor`, but that would require additional changes within `SharedCacheMachOHeader`. `SharedCacheMachOProcessor` now directly accesses the local symbols cache entry rather than needing to search for it.
These files are present alongside iOS 26 shared caches. Explicitly ignoring them avoids an error being logged to the console.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This does the following:
Adds support for relative direct selectors in older shared cache versions.
Prior to macOS 13 / iOS 16, the base offset to use for relative direct selector references within Objective-C message lists was stored within the
__TEXT,__objc_opt_rosection of /usr/lib/libobjc.A.dylib.Reworks handling of .symbols files to be compatible with iOS 15
In some iOS 15 caches, the .symbols file's mapping has an address of 0. This would cause it to be returned by
SharedCache::GetEntryContainingand loaded into the view. The .symbols file contains the local symbol tables for images in the shared cache. It is not intended to be mapped into the same address space as the rest of the shared cache.SharedCachenow tracks the symbols cache entry separately from other entries, andSharedCacheMachOProcessornow directly accesses the local symbols cache entry rather than needing to search for it, and uses the separate VM object for reading data from it.Fixes #7393.