I find it is unrelated to DW_TAG_partial_unit. For example LLDB Python Reference says:
consider that lldb can run in a multithreaded environment, and another thread might call the "script" command, changing the value out from under you.
Therefore if BuildAddressRangeTable called ExtractDIEsIfNeeded(false), then another thread started processing data from m_die_array and then the first thread called final ClearDIEs() the second thread would crash, wouldn't it?
DW_TAG_partial_unit for DWZ would get solved even by this patch.
This patch requires D46810.
Some notes of mine:
ExtractDIEsIfNeeded ro/rw, 0->1, 1->n, 0->n AddUnitDIE rw, called with lock by: DWARFUnit::ExtractDIEsIfNeeded AppendDIEsWithTag ro, called by ParseCompileUnitFunctions, called by Module::ParseAllDebugSymbols after ParseVariablesForContext using ExtractDIEsIfNeeded(false) ClearDIEs ro/rw, called by BuildAddressRangeTable, SymbolFileDWARF::Index GetDIE expand+ro, called by MANY, only using m_die_array after: ExtractDIEsIfNeeded(false) IndexPrivate ro, called by Index, Index called only after: ExtractDIEsIfNeeded(false) GetUnitDIEPtrOnly expand+ro, only using m_die_array after: ExtractDIEsIfNeeded(true) called by BuildAddressRangeTable, ParseProducerInfo, GetLanguageType, GetIsOptimized DIEPtr expand+ro, only using m_die_array after: ExtractDIEsIfNeeded(false) called by BuildAddressRangeTable, GetFunctionAranges
Why don't we expose the llvm::sys::RWMutex for BuildAddressRangeTable and SymbolFileDWARF::Index? Then they can just grab the read lock?