macOS dyld4 introduces a deadlock bug into Profile code

[vtjnash]

AFAIK, there is no possible workaround for this bug in dyld4, aside from forcing the linker to let us use the old dyld2.

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007ff81489ad2e libsystem_kernel.dylib`__ulock_wait + 10
    frame #1: 0x00007ff814903b07 libsystem_platform.dylib`_os_unfair_lock_lock_slow + 162
    frame #2: 0x00007ff8145856f2 dyld`dyld4::RuntimeState::withLoadersReadLock(void () block_pointer) + 34
    frame #3: 0x00007ff8145b04be dyld`dyld4::APIs::findImageMappedAt(void const*, dyld3::MachOLoaded const**, bool*, char const**, void const**, unsigned long long*, unsigned char*) + 784
    frame #4: 0x00007ff8145b078b dyld`dyld4::APIs::dyld_image_path_containing_address(void const*) + 51
    frame #5: 0x00007ff81465822a libsystem_trace.dylib`_os_trace_dylib_or_main_executable_was_loaded + 46
    frame #6: 0x00007ff814589df9 dyld`invocation function for block in dyld4::RuntimeState::notifyLoad(std::__1::span<dyld4::Loader const*, 18446744073709551615ul> const&) + 324
    frame #7: 0x00007ff814585d29 dyld`dyld4::RuntimeState::withNotifiersReadLock(void () block_pointer) + 45
    frame #8: 0x00007ff814589a68 dyld`dyld4::RuntimeState::notifyLoad(std::__1::span<dyld4::Loader const*, 18446744073709551615ul> const&) + 338
    frame #9: 0x00007ff8145b13ea dyld`dyld4::APIs::dlopen_from(char const*, int, void*) + 932

this lock order however is violated here by atfork:
https://github.com/apple-oss-distributions/dyld/blob/c8a445f88f9fc1713db34674e79b00e30723e79d/dyld/DyldRuntimeState.cpp#L2559-L2571

[gbaraldi]

So it's kind of like #49446 but inside their own code?

[vtjnash]

Actually, there are some possible work-arounds, though they are not especially pretty. However, it would be our 3rd such identical work-around for similar bugs in Apple's dyld, so it seems unsurprising at this point. Either, (a) since these are recursive locks, we could theoretically call _dyld_dlopen_atfork_prepare(); _dyld_atfork_prepare(); /* dlopen */; _dyld_atfork_parent(); _dyld_dlopen_atfork_parent(); around every dlopen call to force it to acquire the locks correctly. This defends against use of fork. Additionally, we can add _dyld_dlopen_atfork_parent to our profiling code. This is annoying, since it means dlopen becomes even more of a black box to our profiling code, but should make profiling safe against deadlock from concurrent dlopen (identical to #43701).