Cherrypick Objective-C Runtime Changes #2755
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
(cherry picked from commit ff29fdf)
On Darwin based systems, lldb will get notified by dyld before it itself finished initializing, at which point it's not safe to call certain APIs or SPIs. Add a method to the DynamicLoader to query that. Differential revision: https://reviews.llvm.org/D99314 (cherry picked from commit bbb4191)
The objc_debug_isa_class_mask magic value that the objc runtime vends is now initialized using a static initializer instead of a constant value. The runtime plugin itself will be initialized before the value is computed and as a result, the cache will get the wrong value. Making the creation of the NonPointerIsaCache fully lazy fixes this. (cherry picked from commit c4fee95)
Generic classes in Swift have their name instantiated on request, since the vast majority never need it, and it just wastes time and memory. This results in LLDB being unable to determine the dynamic type of these Swift objects. The main issues is that lazily named classes are not added to the gdb_objc_realized_classes hashtable. This means the class count in the table doesn't change when a class is realized and LLDB doesn't know it needs to re-parse the class info. But even if it did, the classes are not in the hash table. The first change in this patch is that we read objc_debug_realized_class_generation_count and re-parse the class info when the count changes. The second change in this patch is that we use objc_copyRealizedClassList (if available) to get all realized classes from the runtime. Unfortunately, objc_copyRealizedClassList calls _dyld_objc_class_count in its implementation. As we know, the Objective-C parsing code might get called before dyld is fully initialized, resulting in crashes or even a stranded lock. Therefore we only use objc_copyRealizedClassList when we know it's safe to do so by checking libSystemInitialized in dyld_all_image_infos. As a result, it's possible that the first time we read the Objective-C runtime we are forced to use gdb_objc_realized_classes. This should be fine, as there should be no lazily named classes at this point. Subsequent queries will detect the change in realized class generation count and use objc_copyRealizedClassList. This patch keeps the old behavior when objc_copyRealizedClassList or objc_debug_realized_class_generation_count are not available. Differential revision: https://reviews.llvm.org/D99315 (cherry picked from commit 077aa10)
|
@swift-ci please test macos |
3 similar comments
|
@swift-ci please test macos |
|
@swift-ci please test macos |
|
@swift-ci please test macos |
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.
No description provided.