[ORC][MachO] Avoid another race condition in MachOPlatform bootstrap.

Similar to a9e75b1d4d: During MachOPlatform bootstrap we need to defer actions
until essential platform functionality has been loaded, but the platform itself
may be loaded under a concurrent dispatcher so we have to guard against the
deferred actions vector being accessed concurrently.

This fixes a probablistic failure in the ORC runtime regression tests on
Darwin/x86-64 that was spotted after edca1d9bad (which turned on concurrent
linking by default in llvm-jitlink).
This commit is contained in:
Lang Hames
2025-01-03 17:15:33 +11:00
parent febe1a9d28
commit 30b73ed7bd

View File

@@ -937,6 +937,12 @@ Error MachOPlatform::MachOPlatformPlugin::bootstrapPipelineEnd(
jitlink::LinkGraph &G) {
std::lock_guard<std::mutex> Lock(MP.Bootstrap.load()->Mutex);
assert(MP.Bootstrap && "DeferredAAs reset before bootstrap completed");
// Transfer any allocation actions to DeferredAAs.
std::move(G.allocActions().begin(), G.allocActions().end(),
std::back_inserter(MP.Bootstrap.load()->DeferredAAs));
G.allocActions().clear();
--MP.Bootstrap.load()->ActiveGraphs;
// Notify Bootstrap->CV while holding the mutex because the mutex is
// also keeping Bootstrap->CV alive.
@@ -1397,10 +1403,6 @@ Error MachOPlatform::MachOPlatformPlugin::registerObjectPlatformSections(
SPSExecutorAddrRange, SPSExecutorAddrRange>>,
SPSSequence<SPSTuple<SPSString, SPSExecutorAddrRange>>>;
shared::AllocActions &allocActions = LLVM_LIKELY(!InBootstrapPhase)
? G.allocActions()
: MP.Bootstrap.load()->DeferredAAs;
ExecutorAddr HeaderAddr;
{
std::lock_guard<std::mutex> Lock(MP.PlatformMutex);
@@ -1410,7 +1412,7 @@ Error MachOPlatform::MachOPlatformPlugin::registerObjectPlatformSections(
assert(I->second && "Null header registered for JD");
HeaderAddr = I->second;
}
allocActions.push_back(
G.allocActions().push_back(
{cantFail(
WrapperFunctionCall::Create<SPSRegisterObjectPlatformSectionsArgs>(
MP.RegisterObjectPlatformSections.Addr, HeaderAddr, UnwindInfo,