llvm-project/lldb/source/Core/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

109 lines
2.3 KiB
CMake
Raw Normal View History

lldb_tablegen(CoreProperties.inc -gen-lldb-property-defs
SOURCE CoreProperties.td
TARGET LLDBCorePropertiesGen)
lldb_tablegen(CorePropertiesEnum.inc -gen-lldb-property-enum-defs
SOURCE CoreProperties.td
TARGET LLDBCorePropertiesEnumGen)
set(LLDB_CURSES_LIBS)
set(LLDB_LIBEDIT_LIBS)
if (LLDB_ENABLE_CURSES)
list(APPEND LLDB_CURSES_LIBS ${CURSES_LIBRARIES} ${PANEL_LIBRARIES})
if(LLVM_ENABLE_TERMINFO)
list(APPEND LLDB_CURSES_LIBS ${TERMINFO_LIB})
endif()
if (LLVM_BUILD_STATIC)
list(APPEND LLDB_CURSES_LIBS gpm)
endif()
endif()
add_lldb_library(lldbCore
Address.cpp
AddressRange.cpp
AddressResolver.cpp
AddressResolverFileLine.cpp
Communication.cpp
Added the ability to cache the finalized symbol tables subsequent debug sessions to start faster. This is an updated version of the https://reviews.llvm.org/D113789 patch with the following changes: - We no longer modify modification times of the cache files - Use LLVM caching and cache pruning instead of making a new cache mechanism (See DataFileCache.h/.cpp) - Add signature to start of each file since we are not using modification times so we can tell when caches are stale and remove and re-create the cache file as files are changed - Add settings to control the cache size, disk percentage and expiration in days to keep cache size under control This patch enables symbol tables to be cached in the LLDB index cache directory. All cache files are in a single directory and the files use unique names to ensure that files from the same path will re-use the same file as files get modified. This means as files change, their cache files will be deleted and updated. The modification time of each of the cache files is not modified so that access based pruning of the cache can be implemented. The symbol table cache files start with a signature that uniquely identifies a file on disk and contains one or more of the following items: - object file UUID if available - object file mod time if available - object name for BSD archive .o files that are in .a files if available If none of these signature items are available, then the file will not be cached. This keeps temporary object files from expressions from being cached. When the cache files are loaded on subsequent debug sessions, the signature is compare and if the file has been modified (uuid changes, mod time changes, or object file mod time changes) then the cache file is deleted and re-created. Module caching must be enabled by the user before this can be used: symbols.enable-lldb-index-cache (boolean) = false (lldb) settings set symbols.enable-lldb-index-cache true There is also a setting that allows the user to specify a module cache directory that defaults to a directory that defaults to being next to the symbols.clang-modules-cache-path directory in a temp directory: (lldb) settings show symbols.lldb-index-cache-path /var/folders/9p/472sr0c55l9b20x2zg36b91h0000gn/C/lldb/IndexCache If this setting is enabled, the finalized symbol tables will be serialized and saved to disc so they can be quickly loaded next time you debug. Each module can cache one or more files in the index cache directory. The cache file names must be unique to a file on disk and its architecture and object name for .o files in BSD archives. This allows universal mach-o files to support caching multuple architectures in the same module cache directory. Making the file based on the this info allows this cache file to be deleted and replaced when the file gets updated on disk. This keeps the cache from growing over time during the compile/edit/debug cycle and prevents out of space issues. If the cache is enabled, the symbol table will be loaded from the cache the next time you debug if the module has not changed. The cache also has settings to control the size of the cache on disk. Each time LLDB starts up with the index cache enable, the cache will be pruned to ensure it stays within the user defined settings: (lldb) settings set symbols.lldb-index-cache-expiration-days <days> A value of zero will disable cache files from expiring when the cache is pruned. The default value is 7 currently. (lldb) settings set symbols.lldb-index-cache-max-byte-size <size> A value of zero will disable pruning based on a total byte size. The default value is zero currently. (lldb) settings set symbols.lldb-index-cache-max-percent <percentage-of-disk-space> A value of 100 will allow the disc to be filled to the max, a value of zero will disable percentage pruning. The default value is zero. Reviewed By: labath, wallace Differential Revision: https://reviews.llvm.org/D115324
2021-12-17 01:59:25 +08:00
DataFileCache.cpp
Debugger.cpp
DebuggerEvents.cpp
Declaration.cpp
Disassembler.cpp
DumpDataExtractor.cpp
DumpRegisterValue.cpp
DynamicLoader.cpp
EmulateInstruction.cpp
FileLineResolver.cpp
FileSpecList.cpp
FormatEntity.cpp
Highlighter.cpp
IOHandler.cpp
IOHandlerCursesGUI.cpp
Mangled.cpp
Module.cpp
ModuleChild.cpp
ModuleList.cpp
Opcode.cpp
PluginManager.cpp
Progress.cpp
Use rich mangling information in Symtab::InitNameIndexes() Summary: I set up a new review, because not all the code I touched was marked as a change in old one anymore. In preparation for this review, there were two earlier ones: * https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes * https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function Primary goals for this patch are: (1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index. (2) Provide a uniform interface. (3) Improve indexing performance. The central implementation in this patch is our new function for explicit demangling: ``` const RichManglingInfo * Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *) ``` It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are: * `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`). * `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing. The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`. Future potential: * `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.) * The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages. One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess). First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think. Reviewers: labath, jingham, JDevlieghere, erik.pilkington Subscribers: zturner, clayborg, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50071 llvm-svn: 339291
2018-08-09 05:57:37 +08:00
RichManglingContext.cpp
SearchFilter.cpp
Section.cpp
SourceLocationSpec.cpp
SourceManager.cpp
StreamAsynchronousIO.cpp
StreamFile.cpp
UserSettingsController.cpp
Value.cpp
ValueObject.cpp
ValueObjectCast.cpp
ValueObjectChild.cpp
ValueObjectConstResult.cpp
ValueObjectConstResultCast.cpp
ValueObjectConstResultChild.cpp
ValueObjectConstResultImpl.cpp
ValueObjectDynamicValue.cpp
ValueObjectList.cpp
ValueObjectMemory.cpp
ValueObjectRegister.cpp
ValueObjectSyntheticFilter.cpp
ValueObjectUpdater.cpp
ValueObjectVariable.cpp
DEPENDS
clang-tablegen-targets
LINK_LIBS
lldbBreakpoint
lldbDataFormatters
lldbExpression
lldbHost
lldbInterpreter
lldbSymbol
lldbTarget
lldbUtility
lldbPluginCPlusPlusLanguage
lldbPluginObjCLanguage
${LLDB_CURSES_LIBS}
CLANG_LIBS
clangDriver
LINK_COMPONENTS
Support
Demangle
)
add_dependencies(lldbCore
LLDBCorePropertiesGen
LLDBCorePropertiesEnumGen)
# Needed to properly resolve references in a debug build.
# TODO: Remove once we have better layering
set_target_properties(lldbCore PROPERTIES LINK_INTERFACE_MULTIPLICITY 5)
if (LLDB_ENABLE_CURSES)
target_include_directories(lldbCore PRIVATE ${CURSES_INCLUDE_DIRS})
endif()