LLDB regression in 11.6

tapthaker · 2020-10-09T22:34:12.871Z

Xcode LLDB Regression

We are seeing that LLDB takes a very long time to execute the set breakpoint command with Xcode 11.6.
I compared LLDB b/w Xcode 11.2.1 and Xcode 11.6. It seems that the LLDB team has changed the DWARF Debug line parser during this time which is causing slowness than before.
Based on my understanding of the source code ( which is very little ) ⚙ D62570 Use LLVM's debug line parser in LLDB is what caused the regression

LLDB shipped with Xcode 11.2.1

LLDB shipped with Xcode 11.2.12560×1108 754 KB

LLDB shipped with Xcode 11.6

LLDB shipped with Xcode 11.62560×1108 952 KB

You can find the Instruments trace file here

Please let us know if anyone else sees this.

DavidGoldman · 2020-10-09T22:43:01.132Z

I believe we're hitting this as well, one of our developers looked into this a bit and got the following stack trace when hitting a breakpoint with a locally built lldb:

gist.github.com

https://gist.github.com/DavidGoldman/4208d5e7e0950da88afa158a3e0c2538

trace.txt

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x000000011cfeb69d LLDB`compileModuleImpl(ImportingInstance=0x00007fb7f07f2200, ImportLoc=(ID = 0), ModuleName=<unavailable>, Input=FrontendInputFile @ 0x00007ffee2b13600, OriginalModuleMapFile=(Data = "/Users/$USER/git/myswift/build/Ninja-RelWithDebInfoAssert/lldb-macosx-x86_64/bin/LLDB.framework/Resources/Swift/shims/module.modulemap", Length = 136), ModuleFileName=(Data = "/var/folders/_z/hhh0s_5j1g7b8snwvys7v32m00fzy4/C/org.llvm.clang.$USER/ModuleCache/2U4BWNK1FRA3X/SwiftShims-8EXHJ2TPRCHY.pcm", Length = 125), PreBuildStep=function_ref<void (clang::CompilerInstance &)> @ 0x00007ffee2b13690, PostBuildStep=function_ref<void (clang::CompilerInstance &)> @ 0x00007ffee2b136a0)>, llvm::function_ref<void (clang::CompilerInstance&)>) at CompilerInstance.cpp:1178:3 [opt]
    frame #1: 0x000000011cfe8b05 LLDB`clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, clang::Module::NameVisibilityKind, bool) at CompilerInstance.cpp:1253:14 [opt]
    frame #2: 0x000000011cfe867b LLDB`clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, clang::Module::NameVisibilityKind, bool) at CompilerInstance.cpp:1326 [opt]
    frame #3: 0x000000011cfe8311 LLDB`clang::CompilerInstance::loadModule(this=<unavailable>, ImportLoc=<unavailable>, Path=<unavailable>, Visibility=Hidden, IsInclusionDirective=false) at CompilerInstance.cpp:1847 [opt]
    frame #4: 0x000000011b1c85f0 LLDB`swift::ClangImporter::Implementation::loadModuleClang(this=<unavailable>, path=<unavailable>, makeVisible=false)::$_6::operator()(llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, bool) const at ClangImporter.cpp:1725:19 [opt]
    frame #5: 0x000000011b1c831e LLDB`swift::ClangImporter::Implementation::loadModuleClang(this=0x00007fb7e35a5c00, importLoc=<unavailable>, path=<unavailable>) at ClangImporter.cpp:1740:17 [opt]
    frame #6: 0x000000011b1c8aa0 LLDB`swift::ClangImporter::loadModule(this=0x00007fb7e5d53420, importLoc=SourceLoc @ r12, path=ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> > @ 0x00007fa7bb0f5390) at ClangImporter.cpp:1775:25 [opt]
    frame #7: 0x000000011b308155 LLDB`swift::ASTContext::getModule(this=<unavailable>, ModulePath=<unavailable>) at ASTContext.cpp:1756:35 [opt]
    frame #8: 0x000000011b0f955d LLDB`swift::ModuleFile::getModule(this=<unavailable>, name=<unavailable>, allowLoading=<unavailable>) at Deserialization.cpp:1975:25 [opt]

This file has been truncated. show original

From the following part of the stack trace it appears that the non-dSYM DWARF loader calls GetTypeSystemForLanguage for Swift which triggers Clang modules to be built. Using dSYMS seems to workaround this regression (presumably by avoiding this call) but at the cost of slower incremental builds.

    frame #16: 0x000000011b1982c3 LLDB`swift::MemoryBufferSerializedModuleLoader::loadModule(this=0x00007fb7f0138dd0, importLoc=<unavailable>, path=<unavailable>) at SerializedModuleLoader.cpp:925:8 [opt]
    frame #17: 0x000000011b3084a4 LLDB`swift::ASTContext::getModuleByName(llvm::StringRef) at ASTContext.cpp:1756:35 [opt]
    frame #18: 0x000000011b30844d LLDB`swift::ASTContext::getModuleByName(this=0x00007fb7e35a3600, ModuleName=(Data = 0x0000000000000000, Length = 0)) at ASTContext.cpp:1772 [opt]
    frame #19: 0x000000011a0e9ae5 LLDB`lldb_private::SwiftASTContext::GetModule(this=0x00007fb7e5631620, module=0x00007ffee2b14930, error=0x00007ffee2b148f8) at SwiftASTContext.cpp:3761:41 [opt]
    frame #20: 0x000000011a0e5fca LLDB`lldb_private::SwiftASTContext::ValidateSectionModules(this=0x00007fb7e5631620, module=0x00007fb8b2c20ac8, module_names=<unavailable>) at SwiftASTContext.cpp:4349:10 [opt]
    frame #21: 0x000000011a0e2418 LLDB`lldb_private::SwiftASTContext::CreateInstance(language=<unavailable>, module=<unavailable>, target=<unavailable>, fallback=<unavailable>) at SwiftASTContext.cpp:1795:19 [opt]
    frame #22: 0x000000011a0e8aeb LLDB`CreateTypeSystemInstance(language=<unavailable>, module=<unavailable>, target=<unavailable>, extra_options=<unavailable>) at SwiftASTContext.cpp:2264:12 [opt]
    frame #23: 0x000000011a0d1b76 LLDB`lldb_private::TypeSystemMap::GetTypeSystemForLanguage(lldb::LanguageType, lldb_private::Module*, bool) at TypeSystem.cpp:59:9 [opt]
    frame #24: 0x000000011a0d1b32 LLDB`lldb_private::TypeSystemMap::GetTypeSystemForLanguage(lldb::LanguageType, lldb_private::Module*, bool) [inlined] lldb_private::TypeSystem::CreateInstance(language=eLanguageTypeSwift, module=0x00007fb8b2c20ac8) at TypeSystem.cpp:69 [opt]
    frame #25: 0x000000011a0d1b32 LLDB`lldb_private::TypeSystemMap::GetTypeSystemForLanguage(this=<unavailable>, language=<unavailable>, module=0x00007fb8b2c20ac8, can_create=<unavailable>) at TypeSystem.cpp:299 [opt]
    frame #26: 0x0000000119fa67fe LLDB`lldb_private::Module::GetTypeSystemForLanguage(this=<unavailable>, language=<unavailable>) at Module.cpp:360:28 [opt]
    frame #27: 0x000000011a0c3b94 LLDB`lldb_private::SymbolFile::GetTypeSystemForLanguage(this=0x00007fb8b2c0b0c0, language=<unavailable>) at SymbolFile.cpp:95:34 [opt]
    frame #28: 0x000000011a4965c7 LLDB`SymbolFileDWARF::GetTypeSystemForLanguage(this=0x00007fb7f546d400, language=<unavailable>) at SymbolFileDWARF.cpp:436:31 [opt]
    frame #29: 0x000000011a4980d4 LLDB`SymbolFileDWARF::ParseFunction(this=0x00007fb7f546d400, comp_unit=0x00007fb7e562f9b8, die=0x00007ffee2b15128) at SymbolFileDWARF.cpp:805:7 [opt]
    frame #30: 0x000000011a49d1a6 LLDB`SymbolFileDWARF::ResolveSymbolContext(this=0x00007fb7f546d400, so_addr=0x00007ffee2b15190, resolve_scope=eSymbolContextEverything, sc=0x00007ffee2b15310) at SymbolFileDWARF.cpp:1874:33 [opt]
    frame #31: 0x000000011a4acc66 LLDB`SymbolFileDWARFDebugMap::ResolveSymbolContext(this=0x00007fb8b2c0b0c0, exe_so_addr=<unavailable>, resolve_scope=eSymbolContextEverything, sc=0x00007ffee2b15310) at SymbolFileDWARFDebugMap.cpp:791:48 [opt]
    frame #32: 0x0000000119fa6c99 LLDB`lldb_private::Module::ResolveSymbolContextForAddress(this=0x00007fb8b2c20ac8, so_addr=0x00007ffee2b153b0, resolve_scope=eSymbolContextEverything, sc=0x00007ffee2b15310, resolve_tail_call_address=false) at Module.cpp:472:20 [opt]
    frame #33: 0x0000000119f7137b LLDB`lldb_private::Address::CalculateSymbolContext(this=0x00007ffee2b153b0, sc=0x00007ffee2b15310, resolve_scope=eSymbolContextEverything) const at Address.cpp:808:31 [opt]

DavidGoldman · 2020-10-09T22:50:44.069Z

I think there might be two issues here?

Possible regression in lldb due to GetLineTable
lldb eagerly creating SwiftASTContexts

See the SymbolFileDWARF call which ends up calling through to Swift. I wonder if the call to Swift can be avoided or if the Swift call can defer the work until later.

Went ahead and opened [SR-13719] Regression in breakpoint resolution time without dSYMs (dwarf debug map) · Issue #4457 · apple/llvm-project · GitHub for this

JDevlieghere · 2020-10-12T16:30:03.053Z

Hey,

The patch you linked indeed introduced a regression. The issue was related to how we parse the support files.

Prior to my patch of using the LLVM line table parsing code, SymbolFileDWARF::ParseSupportFiles would only parse the line table prologues to get the file list for any files that could be in the line table. If we found the file that someone is setting the breakpoint in in the support files list, we would get a valid index. If we didn't, we would not look any further. So someone sets a breakpoint one "MyFile.cpp:12" and if we find "MyFile.cpp" in the support file list for the compile unit, then and only then would we get the entire line table for that compile unit. Now, no matter what, we always fully parse the line table for all compile units any time any file and line breakpoint is set. This creates a serious problem when debugging a large DWARF in .o file project.

This has since been fixed by ⚙ D81589 [lldb/SymbolFile] Don't parse the whole line table for the support files which we shipped in Xcode 12.

Dave_Lee · 2020-10-12T16:39:22.241Z

@DavidGoldman which version of Xcode is in use for your issues? Note that GetTypeSystemForLanguage doesn't show up as a slow issue in @tapthaker's instruments trace, so whatever you're seeing appears to be a different issue.

tapthaker · 2020-10-12T16:50:19.777Z

Thank you, good to know

DavidGoldman · 2020-10-12T17:24:41.487Z

I just reproduced this issue personally with a Swift app with Xcode 12, trace file here. Updated [SR-13719] Regression in breakpoint resolution time without dSYMs (dwarf debug map) · Issue #4457 · apple/llvm-project · GitHub to link to my trace