The shared cache list of ObjC classes contains classes that are duplicate in name (which
may or may not be duplicate in definition).
Currently, lldb does not handle this list of duplicates correctly. The bugs in the
handling of duplicate classes are in the for loop over the duplicates, which has the
following issues:
- Indexing into the unique class list (classOffsets), not the duplicate list (duplicateClassOffsets)
- Not incrementing idx
The result is that the first N unique classes are wastefully rehashed, where N is
duplicates_count (which can be large).
Note that this change removes the loop over the duplicates altogether, to avoid paying
the cost of ultimately doing nothing.
Ideally, the above bugs could be addressed, however lldb doesn't know which of the
duplicates the ObjC runtime has chosen. When the ObjC runtime registers duplicate
classes, it emits the following error:
Class <class> is implemented in both libA.dylib (0x1048800b8) and libB.dylib
(0x1048700b8). One of the two will be used. Which one is undefined.
In lldb, the code that uses results of this scan does class lookup by name, and doesn't
handle the case where there are multiple classes for a given name. Also, lldb doesn't
know which of the duplicates the ObjC runtime has chosen.
The ultimate fix is to determine which duplicate the ObjC runtime has chosen, and have
lldb use that too.