[lldb] Support lazily named classes in the Objective-C classes
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
Loading
Please register or sign in to comment