In order to avoid stranding the Objective-C runtime lock, we switched
from objc_copyRealizedClassList to its non locking variant
objc_copyRealizedClassList_nolock. Not taking the lock was relatively
safe because we run this expression on one thread only, but it was still
possible that someone was in the middle of modifying this list while we
were trying to read it. Worst case that would result in a crash in the
inferior without side-effects and we'd unwind and try again later.
With the introduction of macOS Ventura, we can use
objc_getRealizedClassList_trylock instead. It has semantics similar to
objc_copyRealizedClassList_nolock, but instead of not locking at all,
the function returns if the lock is already taken, which avoids the
aforementioned crash without stranding the Objective-C runtime lock.
Because LLDB gets to allocate the underlying memory we also avoid
stranding the malloc lock.
rdar://89373233
Differential revision: https://reviews.llvm.org/D127252
LLDB evaluates some utility expression to update the Objective-C class list that
ends up calling function such as `free` or `objc_copyRealizedClassList_nolock`.
This adds a test that just tries to define our own bogus version of
`objc_copyRealizedClassList_nolock`. It just tests that LLDB doesn't crash as we
currently don't have a way to tell LLDB to look for the function in a specific
library.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D107778
