-
Notifications
You must be signed in to change notification settings - Fork 10.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MoveChecker causes false positives with no way to fix #46
Comments
@llvm/issue-subscribers-clang-static-analyzer |
While I agree that such attributes could be helpful, I'm really curious how does the original use case rule out the possibility to simply create a new local variable instead of reusing the storage. In the vastly typical scenario there's simply no incentive to deal with the complexity of storage reuse when local variables are basically free and the moved-from object is typically empty enough to not provide any reuse value. Note that for the non-local variables this check simply doesn't fire; it only fires on non-locals when the class is standard and the semantics of every method are known and the moved-from state is explicitly known to be hazardous, eg. dereference of moved smart pointer (known to be null) or pattern-matching a moved-from string (known to be in unspecified state). |
* [AArch64] Fix mismatch in prologue and epilogue for funclets on Windows The generated code for a funclet can have an add to sp in the epilogue for which there is no corresponding sub in the prologue. This patch removes the early return from emitPrologue that was preventing the sub to sp, and instead conditionalizes the appropriate parts of the rest of the function. Fixes https://bugs.llvm.org/show_bug.cgi?id=45345 Differential Revision: https://reviews.llvm.org/D77015 * [AArch64] Change AArch64 Windows EH UnwindHelp object to be a fixed object The UnwindHelp object is used during exception handling by runtime code. It must be findable from a fixed offset from FP. This change allocates the UnwindHelp object as a fixed object (as is done for x86_64) to ensure that both the generated code and runtime agree on the location of the object. Fixes https://bugs.llvm.org/show_bug.cgi?id=45346 Differential Revision: https://reviews.llvm.org/D77016
the swift branch. The function IRExecutionUnit::PopulateSymtab() is only implemented in swift-lldb. One thing it does is resolve any unresolved global symbols in the JIT module. This global search can cause the JIT module to recursively be asked for its symtab. This patch works around the problem by removing the JIT module from the list of modules being searched while in PopulateSymtab. That isn't done in the most elegant fashion, as it does so by changing the state of the IRExecutionUnit object. (lldb) bt * thread llvm#2, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00007ff80dc2a0ce libsystem_kernel.dylib`__psynch_cvwait + 10 frame llvm#1: 0x00007ff80dc66758 libsystem_pthread.dylib`_pthread_cond_wait + 1242 frame llvm#2: 0x00007ff80dba51fd libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 70 frame llvm#3: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt] * frame llvm#4: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt] frame llvm#5: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt] frame llvm#6: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20600) at SymbolFileSymtab.cpp:60:42 [opt] frame llvm#7: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20600) at SymbolFile.h:478:21 [opt] frame llvm#8: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt] frame llvm#9: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b05a0, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt] frame llvm#10: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt] frame llvm#11: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt] frame llvm#12: 0x000000014fe8c4c0 LLDB`lldb_private::Module::FindFunctions(lldb_private::ConstString, lldb_private::CompilerDeclContext const&, lldb::FunctionNameType, lldb_private::ModuleFunctionSearchOptions const&, lldb_private::SymbolContextList&) at Module.cpp:857:29 [opt] frame llvm#13: 0x000000014fe8c4b0 LLDB`lldb_private::Module::FindFunctions(this=0x0000000106589ca0, name=<unavailable>, parent_decl_ctx=0x00007ff7bfef98d0, name_type_mask=eFunctionNameTypeFull, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) at Module.cpp:878:3 [opt] frame llvm#14: 0x000000014fe92ba1 LLDB`lldb_private::ModuleList::FindFunctions(this=<unavailable>, name=<unavailable>, name_type_mask=<unavailable>, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) const at ModuleList.cpp:554:18 [opt] frame llvm#15: 0x000000014fef36cb LLDB`lldb_private::IRExecutionUnit::FindInSymbols(this=<unavailable>, names=<unavailable>, sc=0x00000001004db950, symbol_was_missing_weak=<unavailable>) at IRExecutionUnit.cpp:843:33 [opt] frame llvm#16: 0x000000014fef3c36 LLDB`lldb_private::IRExecutionUnit::FindSymbol(this=0x00000001004db860, name=<unavailable>, missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:915:22 [opt] frame llvm#17: 0x000000014fef43f3 LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(this=0x0000000107c71000, Name="_$sBoWV", missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:1010:31 [opt] frame llvm#18: 0x000000014fef4490 LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) [inlined] lldb_private::IRExecutionUnit::MemoryManager::findSymbol(this=<unavailable>, Name=<unavailable>) at IRExecutionUnit.cpp:988:21 [opt] frame llvm#19: 0x000000014fef447d LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) at IRExecutionUnit.cpp:0 [opt] frame llvm#20: 0x0000000154ab3a5c LLDB`llvm::LinkingSymbolResolver::findSymbol(this=0x0000000107e0ecc0, Name="_$sBoWV") at MCJIT.cpp:681:26 [opt] frame llvm#21: 0x0000000154abd458 LLDB`llvm::LegacyJITSymbolResolver::lookup(this=<unavailable>, Symbols=<unavailable>, OnResolved=<unavailable>)>) at JITSymbol.cpp:125:22 [opt] frame llvm#22: 0x0000000154abf6f3 LLDB`llvm::RuntimeDyldImpl::resolveExternalSymbols(this=0x000000013cfeea20) at RuntimeDyld.cpp:1195:16 [opt] frame llvm#23: 0x0000000154abecde LLDB`llvm::RuntimeDyldImpl::resolveRelocations(this=0x000000013cfeea20) at RuntimeDyld.cpp:131:18 [opt] frame llvm#24: 0x0000000154ab1482 LLDB`llvm::MCJIT::finalizeLoadedModules(this=0x0000000107e0ea00) at MCJIT.cpp:242:8 [opt] frame llvm#25: 0x0000000154ab24ec LLDB`llvm::MCJIT::getGlobalValueAddress(this=0x0000000107e0ea00, Name=<unavailable>) at MCJIT.cpp:400:5 [opt] frame llvm#26: 0x000000014fef499d LLDB`lldb_private::IRExecutionUnit::PopulateSymtab(this=0x00000001004db860, obj_file=<unavailable>, symtab=0x0000600003342f80) at IRExecutionUnit.cpp:1246:34 [opt] frame llvm#27: 0x00000001503e4bf1 LLDB`ObjectFileJIT::ParseSymtab(this=0x0000600003d04f18, symtab=0x0000600003342f80) at ObjectFileJIT.cpp:112:18 [opt] frame llvm#28: 0x000000014ff93a14 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) at ObjectFile.cpp:764:9 [opt] frame llvm#29: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] decltype(__f=0x00007ff7bfefa180)::$_0>(fp)()) std::__1::__invoke<lldb_private::ObjectFile::GetSymtab()::$_0>(lldb_private::ObjectFile::GetSymtab()::$_0&&) at type_traits:3918:1 [opt] frame llvm#30: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] void std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::__execute<>(this=<unavailable>, (null)=<unavailable>) at mutex:630:9 [opt] frame llvm#31: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::operator(this=<unavailable>)() at mutex:622:9 [opt] frame llvm#32: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(__vp=<unavailable>) at mutex:658:5 [opt] frame llvm#33: 0x00007ff80dba5242 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139 frame llvm#34: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt] frame llvm#35: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt] frame llvm#36: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt] frame llvm#37: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20100) at SymbolFileSymtab.cpp:60:42 [opt] frame llvm#38: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20100) at SymbolFile.h:478:21 [opt] frame llvm#39: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt] frame llvm#40: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b0560, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt] frame llvm#41: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt] frame llvm#42: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt] frame llvm#43: 0x000000015041f366 LLDB`lldb_private::PlatformDarwin::LocateExecutableScriptingResources(this=<unavailable>, target=0x000000010309e800, module=0x0000000106589ca0, feedback_stream=0x00007ff7bfefa770) at PlatformDarwin.cpp:212:40 [opt] frame llvm#44: 0x000000014fe8f97c LLDB`lldb_private::Module::LoadScriptingResourceInTarget(this=<unavailable>, target=0x000000010309e800, error=0x00007ff7bfefa750, feedback_stream=<unavailable>) at Module.cpp:1588:44 [opt] frame llvm#45: 0x0000000150027520 LLDB`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] LoadScriptingResourceForModule(module_sp=<unavailable>, target=0x000000010309e800) at Target.cpp:1415:32 [opt] frame llvm#46: 0x00000001500274f4 LLDB`lldb_private::Target::ModulesDidLoad(this=0x000000010309e800, module_list=<unavailable>) at Target.cpp:1672:7 [opt] frame llvm#47: 0x00000001500284ca LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:1637:5 [opt] frame llvm#48: 0x00000001500284a7 LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:0 [opt] frame llvm#49: 0x000000014fe91f8b LLDB`lldb_private::ModuleList::Append(std::__1::shared_ptr<lldb_private::Module> const&, bool) at ModuleList.cpp:334:19 [opt] frame llvm#50: 0x000000014fe91f44 LLDB`lldb_private::ModuleList::Append(this=0x000000010309eb48, module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, notify=<unavailable>) at ModuleList.cpp:339:3 [opt] frame llvm#51: 0x000000014fef5200 LLDB`lldb_private::IRExecutionUnit::CreateJITModule(this=<unavailable>, name="$__lldb_expr2") at IRExecutionUnit.cpp:1339:27 [opt] frame llvm#52: 0x000000015011063b LLDB`lldb_private::SwiftUserExpression::Parse(this=<unavailable>, diagnostic_manager=<unavailable>, exe_ctx=<unavailable>, execution_policy=eExecutionPolicyOnlyWhenNeeded, keep_result_in_memory=<unavailable>, generate_debug_info=<unavailable>) at SwiftUserExpression.cpp:802:28 [opt] frame llvm#53: 0x000000014ff0cd05 LLDB`lldb_private::UserExpression::Evaluate(exe_ctx=<unavailable>, options=0x00006000033441e0, expr="", prefix="", result_valobj_sp=nullptr, error=0x00007ff7bfefaf40, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at UserExpression.cpp:281:27 [opt] frame llvm#54: 0x000000015002e124 LLDB`lldb_private::Target::EvaluateExpression(this=0x000000010309e800, expr="", exe_scope=<unavailable>, result_valobj_sp=nullptr, options=<unavailable>, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at Target.cpp:2960:25 [opt] frame llvm#55: 0x000000014fcc3e62 LLDB`lldb::SBFrame::EvaluateExpression(this=<unavailable>, expr=<unavailable>, options=0x0000600000011880) at SBFrame.cpp:1084:17 [opt] frame llvm#56: 0x000000014fdaaf70 LLDB`_wrap_SBFrame_EvaluateExpression(_object*, _object*) at LLDBWrapPython.cpp:32887:22 [opt] frame llvm#57: 0x000000014fdaaebf LLDB`_wrap_SBFrame_EvaluateExpression(self=<unavailable>, args=<unavailable>) at LLDBWrapPython.cpp:32933:18 [opt]
the swift branch. The function IRExecutionUnit::PopulateSymtab() is only implemented in swift-lldb. One thing it does is resolve any unresolved global symbols in the JIT module. This global search can cause the JIT module to recursively be asked for its symtab. This patch works around the problem by removing the JIT module from the list of modules being searched while in PopulateSymtab. That isn't done in the most elegant fashion, as it does so by changing the state of the IRExecutionUnit object. (lldb) bt * thread llvm#2, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00007ff80dc2a0ce libsystem_kernel.dylib`__psynch_cvwait + 10 frame llvm#1: 0x00007ff80dc66758 libsystem_pthread.dylib`_pthread_cond_wait + 1242 frame llvm#2: 0x00007ff80dba51fd libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 70 frame llvm#3: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt] * frame llvm#4: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt] frame llvm#5: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt] frame llvm#6: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20600) at SymbolFileSymtab.cpp:60:42 [opt] frame llvm#7: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20600) at SymbolFile.h:478:21 [opt] frame llvm#8: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt] frame llvm#9: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b05a0, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt] frame llvm#10: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt] frame llvm#11: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt] frame llvm#12: 0x000000014fe8c4c0 LLDB`lldb_private::Module::FindFunctions(lldb_private::ConstString, lldb_private::CompilerDeclContext const&, lldb::FunctionNameType, lldb_private::ModuleFunctionSearchOptions const&, lldb_private::SymbolContextList&) at Module.cpp:857:29 [opt] frame llvm#13: 0x000000014fe8c4b0 LLDB`lldb_private::Module::FindFunctions(this=0x0000000106589ca0, name=<unavailable>, parent_decl_ctx=0x00007ff7bfef98d0, name_type_mask=eFunctionNameTypeFull, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) at Module.cpp:878:3 [opt] frame llvm#14: 0x000000014fe92ba1 LLDB`lldb_private::ModuleList::FindFunctions(this=<unavailable>, name=<unavailable>, name_type_mask=<unavailable>, options=0x00007ff7bfef9990, sc_list=0x00007ff7bfef9960) const at ModuleList.cpp:554:18 [opt] frame llvm#15: 0x000000014fef36cb LLDB`lldb_private::IRExecutionUnit::FindInSymbols(this=<unavailable>, names=<unavailable>, sc=0x00000001004db950, symbol_was_missing_weak=<unavailable>) at IRExecutionUnit.cpp:843:33 [opt] frame llvm#16: 0x000000014fef3c36 LLDB`lldb_private::IRExecutionUnit::FindSymbol(this=0x00000001004db860, name=<unavailable>, missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:915:22 [opt] frame llvm#17: 0x000000014fef43f3 LLDB`lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence(this=0x0000000107c71000, Name="_$sBoWV", missing_weak=0x00007ff7bfef9a97) at IRExecutionUnit.cpp:1010:31 [opt] frame llvm#18: 0x000000014fef4490 LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) [inlined] lldb_private::IRExecutionUnit::MemoryManager::findSymbol(this=<unavailable>, Name=<unavailable>) at IRExecutionUnit.cpp:988:21 [opt] frame llvm#19: 0x000000014fef447d LLDB`non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) at IRExecutionUnit.cpp:0 [opt] frame llvm#20: 0x0000000154ab3a5c LLDB`llvm::LinkingSymbolResolver::findSymbol(this=0x0000000107e0ecc0, Name="_$sBoWV") at MCJIT.cpp:681:26 [opt] frame llvm#21: 0x0000000154abd458 LLDB`llvm::LegacyJITSymbolResolver::lookup(this=<unavailable>, Symbols=<unavailable>, OnResolved=<unavailable>)>) at JITSymbol.cpp:125:22 [opt] frame llvm#22: 0x0000000154abf6f3 LLDB`llvm::RuntimeDyldImpl::resolveExternalSymbols(this=0x000000013cfeea20) at RuntimeDyld.cpp:1195:16 [opt] frame llvm#23: 0x0000000154abecde LLDB`llvm::RuntimeDyldImpl::resolveRelocations(this=0x000000013cfeea20) at RuntimeDyld.cpp:131:18 [opt] frame llvm#24: 0x0000000154ab1482 LLDB`llvm::MCJIT::finalizeLoadedModules(this=0x0000000107e0ea00) at MCJIT.cpp:242:8 [opt] frame llvm#25: 0x0000000154ab24ec LLDB`llvm::MCJIT::getGlobalValueAddress(this=0x0000000107e0ea00, Name=<unavailable>) at MCJIT.cpp:400:5 [opt] frame llvm#26: 0x000000014fef499d LLDB`lldb_private::IRExecutionUnit::PopulateSymtab(this=0x00000001004db860, obj_file=<unavailable>, symtab=0x0000600003342f80) at IRExecutionUnit.cpp:1246:34 [opt] frame llvm#27: 0x00000001503e4bf1 LLDB`ObjectFileJIT::ParseSymtab(this=0x0000600003d04f18, symtab=0x0000600003342f80) at ObjectFileJIT.cpp:112:18 [opt] frame llvm#28: 0x000000014ff93a14 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) at ObjectFile.cpp:764:9 [opt] frame llvm#29: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] decltype(__f=0x00007ff7bfefa180)::$_0>(fp)()) std::__1::__invoke<lldb_private::ObjectFile::GetSymtab()::$_0>(lldb_private::ObjectFile::GetSymtab()::$_0&&) at type_traits:3918:1 [opt] frame llvm#30: 0x000000014ff93998 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] void std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::__execute<>(this=<unavailable>, (null)=<unavailable>) at mutex:630:9 [opt] frame llvm#31: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(void*) [inlined] std::__1::__call_once_param<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >::operator(this=<unavailable>)() at mutex:622:9 [opt] frame llvm#32: 0x000000014ff93984 LLDB`void std::__1::__call_once_proxy<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&> >(__vp=<unavailable>) at mutex:658:5 [opt] frame llvm#33: 0x00007ff80dba5242 libc++.1.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 139 frame llvm#34: 0x000000014ff9235d LLDB`lldb_private::ObjectFile::GetSymtab() at mutex:676:9 [opt] frame llvm#35: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab() [inlined] void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=<unavailable>, F=<unavailable>)::$_0&&) at Threading.h:89:5 [opt] frame llvm#36: 0x000000014ff92334 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000600003d04f18) at ObjectFile.cpp:758:5 [opt] frame llvm#37: 0x0000000150531d67 LLDB`SymbolFileSymtab::CalculateAbilities(this=0x0000600003e20100) at SymbolFileSymtab.cpp:60:42 [opt] frame llvm#38: 0x000000015053001d LLDB`lldb_private::SymbolFileCommon::GetAbilities(this=0x0000600003e20100) at SymbolFile.h:478:21 [opt] frame llvm#39: 0x000000014ff9a8cd LLDB`lldb_private::SymbolFile::FindPlugin(objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolFile.cpp:71:62 [opt] frame llvm#40: 0x000000014ff9f4bd LLDB`lldb_private::SymbolVendor::AddSymbolFileRepresentation(this=0x00006000002b0560, objfile_sp=std::__1::shared_ptr<lldb_private::ObjectFile>::element_type @ 0x0000600003d04f18 strong=7 weak=2) at SymbolVendor.cpp:71:27 [opt] frame llvm#41: 0x000000014ff9f419 LLDB`lldb_private::SymbolVendor::FindPlugin(module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, feedback_strm=0x0000000000000000) at SymbolVendor.cpp:57:16 [opt] frame llvm#42: 0x000000014fe8d2a0 LLDB`lldb_private::Module::GetSymbolFile(this=0x0000000106589ca0, can_create=<unavailable>, feedback_strm=0x0000000000000000) at Module.cpp:1083:13 [opt] frame llvm#43: 0x000000015041f366 LLDB`lldb_private::PlatformDarwin::LocateExecutableScriptingResources(this=<unavailable>, target=0x000000010309e800, module=0x0000000106589ca0, feedback_stream=0x00007ff7bfefa770) at PlatformDarwin.cpp:212:40 [opt] frame llvm#44: 0x000000014fe8f97c LLDB`lldb_private::Module::LoadScriptingResourceInTarget(this=<unavailable>, target=0x000000010309e800, error=0x00007ff7bfefa750, feedback_stream=<unavailable>) at Module.cpp:1588:44 [opt] frame llvm#45: 0x0000000150027520 LLDB`lldb_private::Target::ModulesDidLoad(lldb_private::ModuleList&) [inlined] LoadScriptingResourceForModule(module_sp=<unavailable>, target=0x000000010309e800) at Target.cpp:1415:32 [opt] frame llvm#46: 0x00000001500274f4 LLDB`lldb_private::Target::ModulesDidLoad(this=0x000000010309e800, module_list=<unavailable>) at Target.cpp:1672:7 [opt] frame llvm#47: 0x00000001500284ca LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:1637:5 [opt] frame llvm#48: 0x00000001500284a7 LLDB`non-virtual thunk to lldb_private::Target::NotifyModuleAdded(lldb_private::ModuleList const&, std::__1::shared_ptr<lldb_private::Module> const&) at Target.cpp:0 [opt] frame llvm#49: 0x000000014fe91f8b LLDB`lldb_private::ModuleList::Append(std::__1::shared_ptr<lldb_private::Module> const&, bool) at ModuleList.cpp:334:19 [opt] frame llvm#50: 0x000000014fe91f44 LLDB`lldb_private::ModuleList::Append(this=0x000000010309eb48, module_sp=std::__1::shared_ptr<lldb_private::Module>::element_type @ 0x0000000106589ca0 strong=12 weak=26, notify=<unavailable>) at ModuleList.cpp:339:3 [opt] frame llvm#51: 0x000000014fef5200 LLDB`lldb_private::IRExecutionUnit::CreateJITModule(this=<unavailable>, name="$__lldb_expr2") at IRExecutionUnit.cpp:1339:27 [opt] frame llvm#52: 0x000000015011063b LLDB`lldb_private::SwiftUserExpression::Parse(this=<unavailable>, diagnostic_manager=<unavailable>, exe_ctx=<unavailable>, execution_policy=eExecutionPolicyOnlyWhenNeeded, keep_result_in_memory=<unavailable>, generate_debug_info=<unavailable>) at SwiftUserExpression.cpp:802:28 [opt] frame llvm#53: 0x000000014ff0cd05 LLDB`lldb_private::UserExpression::Evaluate(exe_ctx=<unavailable>, options=0x00006000033441e0, expr="", prefix="", result_valobj_sp=nullptr, error=0x00007ff7bfefaf40, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at UserExpression.cpp:281:27 [opt] frame llvm#54: 0x000000015002e124 LLDB`lldb_private::Target::EvaluateExpression(this=0x000000010309e800, expr="", exe_scope=<unavailable>, result_valobj_sp=nullptr, options=<unavailable>, fixed_expression=Summary Unavailable, ctx_obj=0x0000000000000000) at Target.cpp:2960:25 [opt] frame llvm#55: 0x000000014fcc3e62 LLDB`lldb::SBFrame::EvaluateExpression(this=<unavailable>, expr=<unavailable>, options=0x0000600000011880) at SBFrame.cpp:1084:17 [opt] frame llvm#56: 0x000000014fdaaf70 LLDB`_wrap_SBFrame_EvaluateExpression(_object*, _object*) at LLDBWrapPython.cpp:32887:22 [opt] frame llvm#57: 0x000000014fdaaebf LLDB`_wrap_SBFrame_EvaluateExpression(self=<unavailable>, args=<unavailable>) at LLDBWrapPython.cpp:32933:18 [opt] (cherry picked from commit ba81700)
There is a SIGSEGV at `DeduceTemplateArgumentsByTypeMatch`. The bug [llvm#51171](https://bugs.llvm.org/show_bug.cgi?id=51171) was filled. The reproducer can be found at the bug description. LIT test for the issue was added: ``` ./bin/llvm-lit -v ../clang/test/SemaCXX/pr51171-crash.cpp ``` The debug stack trace is below: ``` #0 0x00000000055afcb9 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:22 llvm#1 0x00000000055afd70 PrintStackTraceSignalHandler(void*) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:1 llvm#2 0x00000000055add2d llvm::sys::RunSignalHandlers() /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Signals.cpp:97:20 llvm#3 0x00000000055af701 SignalHandler(int) /home/ivanmurashko/local/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:1 llvm#4 0x00007ffff7bc2b20 __restore_rt sigaction.c:0:0 llvm#5 0x00007ffff66a337f raise (/lib64/libc.so.6+0x3737f) llvm#6 0x00007ffff668ddb5 abort (/lib64/libc.so.6+0x21db5) llvm#7 0x00007ffff668dc89 _nl_load_domain.cold.0 loadmsgcat.c:0:0 llvm#8 0x00007ffff669ba76 .annobin___GI___assert_fail.end assert.c:0:0 llvm#9 0x000000000594b210 clang::QualType::getCommonPtr() const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/Type.h:684:5 llvm#10 0x0000000005a12ca6 clang::QualType::getCanonicalType() const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/Type.h:6467:36 llvm#11 0x0000000005a137a6 clang::ASTContext::getCanonicalType(clang::QualType) const /home/ivanmurashko/local/llvm-project/clang/include/clang/AST/ASTContext.h:2433:58 llvm#12 0x0000000009204584 DeduceTemplateArgumentsByTypeMatch(clang::Sema&, clang::TemplateParameterList*, clang::QualType, clang::QualType, clang::sema::TemplateDeductionInfo&, llvm::SmallVectorImpl<clang::DeducedTemplateArgument>&, unsigned int, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:1355:54 llvm#13 0x000000000920df0d clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*, clang::TemplateArgumentListInfo*, clang::QualType, clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4354:47 llvm#14 0x0000000009012b09 (anonymous namespace)::AddressOfFunctionResolver::AddMatchingTemplateFunction(clang::FunctionTemplateDecl*, clang::DeclAccessPair const&) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12026:38 llvm#15 0x0000000009013030 (anonymous namespace)::AddressOfFunctionResolver::FindAllFunctionsThatMatchTargetTypeExactly() /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12119:9 llvm#16 0x0000000009012679 (anonymous namespace)::AddressOfFunctionResolver::AddressOfFunctionResolver(clang::Sema&, clang::Expr*, clang::QualType const&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:11931:5 llvm#17 0x0000000009013c91 clang::Sema::ResolveAddressOfOverloadedFunction(clang::Expr*, clang::QualType, bool, clang::DeclAccessPair&, bool*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:12286:42 llvm#18 0x0000000008fed85d IsStandardConversion(clang::Sema&, clang::Expr*, clang::QualType, bool, clang::StandardConversionSequence&, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:1712:49 llvm#19 0x0000000008fec8ea TryImplicitConversion(clang::Sema&, clang::Expr*, clang::QualType, bool, clang::Sema::AllowedExplicit, bool, bool, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:1433:27 llvm#20 0x0000000008ff90ba TryCopyInitialization(clang::Sema&, clang::Expr*, clang::QualType, bool, bool, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:5273:71 llvm#21 0x00000000090024fb clang::Sema::AddBuiltinCandidate(clang::QualType*, llvm::ArrayRef<clang::Expr*>, clang::OverloadCandidateSet&, bool, unsigned int) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:7755:32 llvm#22 0x000000000900513f (anonymous namespace)::BuiltinOperatorOverloadBuilder::addGenericBinaryArithmeticOverloads() /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:8633:30 llvm#23 0x0000000009007624 clang::Sema::AddBuiltinOperatorCandidates(clang::OverloadedOperatorKind, clang::SourceLocation, llvm::ArrayRef<clang::Expr*>, clang::OverloadCandidateSet&) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:9205:51 llvm#24 0x0000000009018734 clang::Sema::LookupOverloadedBinOp(clang::OverloadCandidateSet&, clang::OverloadedOperatorKind, clang::UnresolvedSetImpl const&, llvm::ArrayRef<clang::Expr*>, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:13469:1 llvm#25 0x0000000009018d56 clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, clang::BinaryOperatorKind, clang::UnresolvedSetImpl const&, clang::Expr*, clang::Expr*, bool, bool, clang::FunctionDecl*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaOverload.cpp:13568:24 llvm#26 0x0000000008b24797 BuildOverloadedBinOp(clang::Sema&, clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14606:65 llvm#27 0x0000000008b24ed5 clang::Sema::BuildBinOp(clang::Scope*, clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14691:73 llvm#28 0x0000000008b245d4 clang::Sema::ActOnBinOp(clang::Scope*, clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) /home/ivanmurashko/local/llvm-project/clang/lib/Sema/SemaExpr.cpp:14566:1 llvm#29 0x00000000085bfafb clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*, true>, clang::prec::Level) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:630:71 llvm#30 0x00000000085bd922 clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:177:1 llvm#31 0x00000000085cbbcd clang::Parser::ParseExpressionList(llvm::SmallVectorImpl<clang::Expr*>&, llvm::SmallVectorImpl<clang::SourceLocation>&, llvm::function_ref<void ()>) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseExpr.cpp:3368:40 llvm#32 0x000000000857f49c clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseDecl.cpp:2416:5 llvm#33 0x000000000857df16 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseDecl.cpp:2092:65 llvm#34 0x000000000855f07b clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:1138:1 llvm#35 0x000000000855f136 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:1153:57 llvm#36 0x000000000855e644 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributesWithRange&, clang::ParsingDeclSpec*) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:975:58 llvm#37 0x000000000855d717 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/Parser.cpp:720:42 llvm#38 0x0000000008558e01 clang::ParseAST(clang::Sema&, bool, bool) /home/ivanmurashko/local/llvm-project/clang/lib/Parse/ParseAST.cpp:158:37 llvm#39 0x000000000627a221 clang::ASTFrontendAction::ExecuteAction() /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/FrontendAction.cpp:1058:11 llvm#40 0x0000000006bdcc31 clang::CodeGenAction::ExecuteAction() /home/ivanmurashko/local/llvm-project/clang/lib/CodeGen/CodeGenAction.cpp:1045:5 llvm#41 0x0000000006279b4d clang::FrontendAction::Execute() /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/FrontendAction.cpp:955:38 llvm#42 0x00000000061c3fe9 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /home/ivanmurashko/local/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:974:42 llvm#43 0x00000000063f9c5e clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /home/ivanmurashko/local/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:38 llvm#44 0x0000000002603a03 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /home/ivanmurashko/local/llvm-project/clang/tools/driver/cc1_main.cpp:246:40 llvm#45 0x00000000025f8a39 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /home/ivanmurashko/local/llvm-project/clang/tools/driver/driver.cpp:338:20 llvm#46 0x00000000025f9107 main /home/ivanmurashko/local/llvm-project/clang/tools/driver/driver.cpp:415:26 llvm#47 0x00007ffff668f493 __libc_start_main (/lib64/libc.so.6+0x23493) llvm#48 0x00000000025f729e _start (/data/users/ivanmurashko/llvm-project/build/bin/clang-13+0x25f729e) ``` Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D106583
…callback The `TypeSystemMap::m_mutex` guards against concurrent modifications of members of `TypeSystemMap`. In particular, `m_map`. `TypeSystemMap::ForEach` iterates through the entire `m_map` calling a user-specified callback for each entry. This is all done while `m_mutex` is locked. However, there's nothing that guarantees that the callback itself won't call back into `TypeSystemMap` APIs on the same thread. This lead to double-locking `m_mutex`, which is undefined behaviour. We've seen this cause a deadlock in the swift plugin with following backtrace: ``` int main() { std::unique_ptr<int> up = std::make_unique<int>(5); volatile int val = *up; return val; } clang++ -std=c++2a -g -O1 main.cpp ./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b ``` ``` frame llvm#4: std::lock_guard<std::mutex>::lock_guard frame llvm#5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock llvm#2 frame llvm#6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage frame llvm#7: lldb_private::Target::GetScratchTypeSystemForLanguage ... frame llvm#26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths frame llvm#27: lldb_private::SwiftASTContext::LoadModule frame llvm#30: swift::ModuleDecl::collectLinkLibraries frame llvm#31: lldb_private::SwiftASTContext::LoadModule frame llvm#34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl frame llvm#35: lldb_private::SwiftASTContext::PerformCompileUnitImports frame llvm#36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext frame llvm#37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState frame llvm#38: lldb_private::Target::GetPersistentSymbol frame llvm#41: lldb_private::TypeSystemMap::ForEach <<<< Lock llvm#1 frame llvm#42: lldb_private::Target::GetPersistentSymbol frame llvm#43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols frame llvm#44: lldb_private::IRExecutionUnit::FindSymbol frame llvm#45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence frame llvm#46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol frame llvm#47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol frame llvm#48: llvm::LinkingSymbolResolver::findSymbol frame llvm#49: llvm::LegacyJITSymbolResolver::lookup frame llvm#50: llvm::RuntimeDyldImpl::resolveExternalSymbols frame llvm#51: llvm::RuntimeDyldImpl::resolveRelocations frame llvm#52: llvm::MCJIT::finalizeLoadedModules frame llvm#53: llvm::MCJIT::finalizeObject frame llvm#54: lldb_private::IRExecutionUnit::ReportAllocations frame llvm#55: lldb_private::IRExecutionUnit::GetRunnableInfo frame llvm#56: lldb_private::ClangExpressionParser::PrepareForExecution frame llvm#57: lldb_private::ClangUserExpression::TryParse frame llvm#58: lldb_private::ClangUserExpression::Parse ``` Our solution is to simply iterate over a local copy of `m_map`. **Testing** * Confirmed on manual reproducer (would reproduce 100% of the time before the patch) Differential Revision: https://reviews.llvm.org/D149949
…callback The `TypeSystemMap::m_mutex` guards against concurrent modifications of members of `TypeSystemMap`. In particular, `m_map`. `TypeSystemMap::ForEach` iterates through the entire `m_map` calling a user-specified callback for each entry. This is all done while `m_mutex` is locked. However, there's nothing that guarantees that the callback itself won't call back into `TypeSystemMap` APIs on the same thread. This lead to double-locking `m_mutex`, which is undefined behaviour. We've seen this cause a deadlock in the swift plugin with following backtrace: ``` int main() { std::unique_ptr<int> up = std::make_unique<int>(5); volatile int val = *up; return val; } clang++ -std=c++2a -g -O1 main.cpp ./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b ``` ``` frame llvm#4: std::lock_guard<std::mutex>::lock_guard frame llvm#5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock llvm#2 frame llvm#6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage frame llvm#7: lldb_private::Target::GetScratchTypeSystemForLanguage ... frame llvm#26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths frame llvm#27: lldb_private::SwiftASTContext::LoadModule frame llvm#30: swift::ModuleDecl::collectLinkLibraries frame llvm#31: lldb_private::SwiftASTContext::LoadModule frame llvm#34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl frame llvm#35: lldb_private::SwiftASTContext::PerformCompileUnitImports frame llvm#36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext frame llvm#37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState frame llvm#38: lldb_private::Target::GetPersistentSymbol frame llvm#41: lldb_private::TypeSystemMap::ForEach <<<< Lock llvm#1 frame llvm#42: lldb_private::Target::GetPersistentSymbol frame llvm#43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols frame llvm#44: lldb_private::IRExecutionUnit::FindSymbol frame llvm#45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence frame llvm#46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol frame llvm#47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol frame llvm#48: llvm::LinkingSymbolResolver::findSymbol frame llvm#49: llvm::LegacyJITSymbolResolver::lookup frame llvm#50: llvm::RuntimeDyldImpl::resolveExternalSymbols frame llvm#51: llvm::RuntimeDyldImpl::resolveRelocations frame llvm#52: llvm::MCJIT::finalizeLoadedModules frame llvm#53: llvm::MCJIT::finalizeObject frame llvm#54: lldb_private::IRExecutionUnit::ReportAllocations frame llvm#55: lldb_private::IRExecutionUnit::GetRunnableInfo frame llvm#56: lldb_private::ClangExpressionParser::PrepareForExecution frame llvm#57: lldb_private::ClangUserExpression::TryParse frame llvm#58: lldb_private::ClangUserExpression::Parse ``` Our solution is to simply iterate over a local copy of `m_map`. **Testing** * Confirmed on manual reproducer (would reproduce 100% of the time before the patch) Differential Revision: https://reviews.llvm.org/D149949 (cherry picked from commit dda3a6a)
…callback The `TypeSystemMap::m_mutex` guards against concurrent modifications of members of `TypeSystemMap`. In particular, `m_map`. `TypeSystemMap::ForEach` iterates through the entire `m_map` calling a user-specified callback for each entry. This is all done while `m_mutex` is locked. However, there's nothing that guarantees that the callback itself won't call back into `TypeSystemMap` APIs on the same thread. This lead to double-locking `m_mutex`, which is undefined behaviour. We've seen this cause a deadlock in the swift plugin with following backtrace: ``` int main() { std::unique_ptr<int> up = std::make_unique<int>(5); volatile int val = *up; return val; } clang++ -std=c++2a -g -O1 main.cpp ./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b ``` ``` frame #4: std::lock_guard<std::mutex>::lock_guard frame #5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock #2 frame #6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage frame #7: lldb_private::Target::GetScratchTypeSystemForLanguage ... frame #26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths frame #27: lldb_private::SwiftASTContext::LoadModule frame #30: swift::ModuleDecl::collectLinkLibraries frame #31: lldb_private::SwiftASTContext::LoadModule frame #34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl frame #35: lldb_private::SwiftASTContext::PerformCompileUnitImports frame #36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext frame #37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState frame #38: lldb_private::Target::GetPersistentSymbol frame #41: lldb_private::TypeSystemMap::ForEach <<<< Lock #1 frame #42: lldb_private::Target::GetPersistentSymbol frame #43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols frame #44: lldb_private::IRExecutionUnit::FindSymbol frame #45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence frame #46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol frame #47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol frame #48: llvm::LinkingSymbolResolver::findSymbol frame #49: llvm::LegacyJITSymbolResolver::lookup frame #50: llvm::RuntimeDyldImpl::resolveExternalSymbols frame #51: llvm::RuntimeDyldImpl::resolveRelocations frame #52: llvm::MCJIT::finalizeLoadedModules frame #53: llvm::MCJIT::finalizeObject frame #54: lldb_private::IRExecutionUnit::ReportAllocations frame #55: lldb_private::IRExecutionUnit::GetRunnableInfo frame #56: lldb_private::ClangExpressionParser::PrepareForExecution frame #57: lldb_private::ClangUserExpression::TryParse frame #58: lldb_private::ClangUserExpression::Parse ``` Our solution is to simply iterate over a local copy of `m_map`. **Testing** * Confirmed on manual reproducer (would reproduce 100% of the time before the patch) Differential Revision: https://reviews.llvm.org/D149949
…s from 1.0 to xtheadvector (llvm#46) * [Clang][XTHeadVector] Add intrinsic wrapper macros in order to compatible with RVV 1.0 * [Clang][XTHeadVector] Test intrinsic wrapper macros
…s from 1.0 to xtheadvector (llvm#46) * [Clang][XTHeadVector] Add intrinsic wrapper macros in order to compatible with RVV 1.0 * [Clang][XTHeadVector] Test intrinsic wrapper macros
rewrite make_generated_offload_arch script in Python
As a dumb example
Where is_valid is actually a check if this object is usable, the MoveChecker is hardcoded to assume that this function must be called [is]empty. This should presumably be an attribute, such as clang::movesafe so that functions that are coded movesafe can be tagged properly.
Likewise, clang::movestatereset or something like such should be introduced for functions that reset the state (but I haven't had that issue, yet).
The text was updated successfully, but these errors were encountered: