Files
llvm/lldb/source/Symbol/SymbolFileOnDemand.cpp

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

588 lines
20 KiB
C++
Raw Normal View History

2023-09-20 17:43:44 -07:00
//===-- SymbolFileOnDemand.cpp ---------------------------------------===//
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "lldb/Symbol/SymbolFileOnDemand.h"
#include "lldb/Core/Module.h"
#include "lldb/Symbol/SymbolFile.h"
#include <memory>
#include <optional>
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
using namespace lldb;
using namespace lldb_private;
char SymbolFileOnDemand::ID;
SymbolFileOnDemand::SymbolFileOnDemand(
std::unique_ptr<SymbolFile> &&symbol_file)
: m_sym_file_impl(std::move(symbol_file)) {}
SymbolFileOnDemand::~SymbolFileOnDemand() = default;
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
uint32_t SymbolFileOnDemand::CalculateAbilities() {
// Explicitly allow ability checking to pass though.
// This should be a cheap operation.
return m_sym_file_impl->CalculateAbilities();
}
std::recursive_mutex &SymbolFileOnDemand::GetModuleMutex() const {
return m_sym_file_impl->GetModuleMutex();
}
void SymbolFileOnDemand::InitializeObject() {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return;
}
return m_sym_file_impl->InitializeObject();
}
lldb::LanguageType SymbolFileOnDemand::ParseLanguage(CompileUnit &comp_unit) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped", GetSymbolFileName(), __FUNCTION__);
if (log) {
lldb::LanguageType langType = m_sym_file_impl->ParseLanguage(comp_unit);
if (langType != eLanguageTypeUnknown)
LLDB_LOG(log, "Language {0} would return if hydrated.", langType);
}
return eLanguageTypeUnknown;
}
return m_sym_file_impl->ParseLanguage(comp_unit);
}
XcodeSDK SymbolFileOnDemand::ParseXcodeSDK(CompileUnit &comp_unit) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped", GetSymbolFileName(), __FUNCTION__);
XcodeSDK defaultValue{};
if (log) {
XcodeSDK sdk = m_sym_file_impl->ParseXcodeSDK(comp_unit);
if (!(sdk == defaultValue))
LLDB_LOG(log, "SDK {0} would return if hydrated.", sdk.GetString());
}
return defaultValue;
}
return m_sym_file_impl->ParseXcodeSDK(comp_unit);
}
size_t SymbolFileOnDemand::ParseFunctions(CompileUnit &comp_unit) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return 0;
}
return m_sym_file_impl->ParseFunctions(comp_unit);
}
bool SymbolFileOnDemand::ParseLineTable(CompileUnit &comp_unit) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return false;
}
return m_sym_file_impl->ParseLineTable(comp_unit);
}
bool SymbolFileOnDemand::ParseDebugMacros(CompileUnit &comp_unit) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return false;
}
return m_sym_file_impl->ParseDebugMacros(comp_unit);
}
bool SymbolFileOnDemand::ForEachExternalModule(
CompileUnit &comp_unit,
llvm::DenseSet<lldb_private::SymbolFile *> &visited_symbol_files,
llvm::function_ref<bool(Module &)> lambda) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
// Return false to not early exit.
return false;
}
return m_sym_file_impl->ForEachExternalModule(comp_unit, visited_symbol_files,
lambda);
}
bool SymbolFileOnDemand::ParseSupportFiles(CompileUnit &comp_unit,
SupportFileList &support_files) {
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
LLDB_LOG(GetLog(),
"[{0}] {1} is not skipped: explicitly allowed to support breakpoint",
GetSymbolFileName(), __FUNCTION__);
// Explicitly allow this API through to support source line breakpoint.
return m_sym_file_impl->ParseSupportFiles(comp_unit, support_files);
}
bool SymbolFileOnDemand::ParseIsOptimized(CompileUnit &comp_unit) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped", GetSymbolFileName(), __FUNCTION__);
if (log) {
bool optimized = m_sym_file_impl->ParseIsOptimized(comp_unit);
if (optimized) {
LLDB_LOG(log, "Would return optimized if hydrated.");
}
}
return false;
}
return m_sym_file_impl->ParseIsOptimized(comp_unit);
}
size_t SymbolFileOnDemand::ParseTypes(CompileUnit &comp_unit) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return 0;
}
return m_sym_file_impl->ParseTypes(comp_unit);
}
bool SymbolFileOnDemand::ParseImportedModules(
const lldb_private::SymbolContext &sc,
std::vector<SourceModule> &imported_modules) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped", GetSymbolFileName(), __FUNCTION__);
if (log) {
std::vector<SourceModule> tmp_imported_modules;
bool succeed =
m_sym_file_impl->ParseImportedModules(sc, tmp_imported_modules);
if (succeed)
LLDB_LOG(log, "{0} imported modules would be parsed if hydrated.",
tmp_imported_modules.size());
}
return false;
}
return m_sym_file_impl->ParseImportedModules(sc, imported_modules);
}
size_t SymbolFileOnDemand::ParseBlocksRecursive(Function &func) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return 0;
}
return m_sym_file_impl->ParseBlocksRecursive(func);
}
size_t SymbolFileOnDemand::ParseVariablesForContext(const SymbolContext &sc) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return 0;
}
return m_sym_file_impl->ParseVariablesForContext(sc);
}
Type *SymbolFileOnDemand::ResolveTypeUID(lldb::user_id_t type_uid) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped", GetSymbolFileName(), __FUNCTION__);
if (log) {
Type *resolved_type = m_sym_file_impl->ResolveTypeUID(type_uid);
if (resolved_type)
LLDB_LOG(log, "Type would be parsed for {0} if hydrated.", type_uid);
}
return nullptr;
}
return m_sym_file_impl->ResolveTypeUID(type_uid);
}
std::optional<SymbolFile::ArrayInfo>
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
SymbolFileOnDemand::GetDynamicArrayInfoForUID(
lldb::user_id_t type_uid, const lldb_private::ExecutionContext *exe_ctx) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return std::nullopt;
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
}
return m_sym_file_impl->GetDynamicArrayInfoForUID(type_uid, exe_ctx);
}
bool SymbolFileOnDemand::CompleteType(CompilerType &compiler_type) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return false;
}
return m_sym_file_impl->CompleteType(compiler_type);
}
CompilerDecl SymbolFileOnDemand::GetDeclForUID(lldb::user_id_t type_uid) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped", GetSymbolFileName(), __FUNCTION__);
if (log) {
CompilerDecl parsed_decl = m_sym_file_impl->GetDeclForUID(type_uid);
if (parsed_decl != CompilerDecl()) {
LLDB_LOG(log, "CompilerDecl {0} would be parsed for {1} if hydrated.",
parsed_decl.GetName(), type_uid);
}
}
return CompilerDecl();
}
return m_sym_file_impl->GetDeclForUID(type_uid);
}
CompilerDeclContext
SymbolFileOnDemand::GetDeclContextForUID(lldb::user_id_t type_uid) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return CompilerDeclContext();
}
return m_sym_file_impl->GetDeclContextForUID(type_uid);
}
CompilerDeclContext
SymbolFileOnDemand::GetDeclContextContainingUID(lldb::user_id_t type_uid) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return CompilerDeclContext();
}
return m_sym_file_impl->GetDeclContextContainingUID(type_uid);
}
void SymbolFileOnDemand::ParseDeclsForContext(CompilerDeclContext decl_ctx) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return;
}
return m_sym_file_impl->ParseDeclsForContext(decl_ctx);
}
uint32_t
SymbolFileOnDemand::ResolveSymbolContext(const Address &so_addr,
SymbolContextItem resolve_scope,
SymbolContext &sc) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return 0;
}
return m_sym_file_impl->ResolveSymbolContext(so_addr, resolve_scope, sc);
}
Status SymbolFileOnDemand::CalculateFrameVariableError(StackFrame &frame) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return Status();
}
return m_sym_file_impl->CalculateFrameVariableError(frame);
}
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
uint32_t SymbolFileOnDemand::ResolveSymbolContext(
const SourceLocationSpec &src_location_spec,
SymbolContextItem resolve_scope, SymbolContextList &sc_list) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return 0;
}
return m_sym_file_impl->ResolveSymbolContext(src_location_spec, resolve_scope,
sc_list);
}
void SymbolFileOnDemand::Dump(lldb_private::Stream &s) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return;
}
return m_sym_file_impl->Dump(s);
}
void SymbolFileOnDemand::DumpClangAST(lldb_private::Stream &s) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return;
}
return m_sym_file_impl->DumpClangAST(s);
}
void SymbolFileOnDemand::FindGlobalVariables(const RegularExpression &regex,
uint32_t max_matches,
VariableList &variables) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return;
}
return m_sym_file_impl->FindGlobalVariables(regex, max_matches, variables);
}
void SymbolFileOnDemand::FindGlobalVariables(
ConstString name, const CompilerDeclContext &parent_decl_ctx,
uint32_t max_matches, VariableList &variables) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
Symtab *symtab = GetSymtab();
if (!symtab) {
LLDB_LOG(log, "[{0}] {1} is skipped - fail to get symtab",
GetSymbolFileName(), __FUNCTION__);
return;
}
Symbol *sym = symtab->FindFirstSymbolWithNameAndType(
name, eSymbolTypeData, Symtab::eDebugAny, Symtab::eVisibilityAny);
if (!sym) {
LLDB_LOG(log, "[{0}] {1} is skipped - fail to find match in symtab",
GetSymbolFileName(), __FUNCTION__);
return;
}
LLDB_LOG(log, "[{0}] {1} is NOT skipped - found match in symtab",
GetSymbolFileName(), __FUNCTION__);
// Found match in symbol table hydrate debug info and
// allow the FindGlobalVariables to go through.
SetLoadDebugInfoEnabled();
}
return m_sym_file_impl->FindGlobalVariables(name, parent_decl_ctx,
max_matches, variables);
}
void SymbolFileOnDemand::FindFunctions(const RegularExpression &regex,
bool include_inlines,
SymbolContextList &sc_list) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
Symtab *symtab = GetSymtab();
if (!symtab) {
LLDB_LOG(log, "[{0}] {1} is skipped - fail to get symtab",
GetSymbolFileName(), __FUNCTION__);
return;
}
std::vector<uint32_t> symbol_indexes;
symtab->AppendSymbolIndexesMatchingRegExAndType(
regex, eSymbolTypeAny, Symtab::eDebugAny, Symtab::eVisibilityAny,
symbol_indexes);
if (symbol_indexes.empty()) {
LLDB_LOG(log, "[{0}] {1} is skipped - fail to find match in symtab",
GetSymbolFileName(), __FUNCTION__);
return;
}
LLDB_LOG(log, "[{0}] {1} is NOT skipped - found match in symtab",
GetSymbolFileName(), __FUNCTION__);
// Found match in symbol table hydrate debug info and
// allow the FindFucntions to go through.
SetLoadDebugInfoEnabled();
}
return m_sym_file_impl->FindFunctions(regex, include_inlines, sc_list);
}
void SymbolFileOnDemand::FindFunctions(
const Module::LookupInfo &lookup_info,
const CompilerDeclContext &parent_decl_ctx, bool include_inlines,
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
SymbolContextList &sc_list) {
ConstString name = lookup_info.GetLookupName();
FunctionNameType name_type_mask = lookup_info.GetNameTypeMask();
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
if (!m_debug_info_enabled) {
Log *log = GetLog();
Symtab *symtab = GetSymtab();
if (!symtab) {
LLDB_LOG(log, "[{0}] {1}({2}) is skipped - fail to get symtab",
GetSymbolFileName(), __FUNCTION__, name);
return;
}
SymbolContextList sc_list_helper;
symtab->FindFunctionSymbols(name, name_type_mask, sc_list_helper);
if (sc_list_helper.GetSize() == 0) {
LLDB_LOG(log, "[{0}] {1}({2}) is skipped - fail to find match in symtab",
GetSymbolFileName(), __FUNCTION__, name);
return;
}
LLDB_LOG(log, "[{0}] {1}({2}) is NOT skipped - found match in symtab",
GetSymbolFileName(), __FUNCTION__, name);
// Found match in symbol table hydrate debug info and
// allow the FindFucntions to go through.
SetLoadDebugInfoEnabled();
}
return m_sym_file_impl->FindFunctions(lookup_info, parent_decl_ctx,
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
include_inlines, sc_list);
}
void SymbolFileOnDemand::GetMangledNamesForFunction(
const std::string &scope_qualified_name,
std::vector<ConstString> &mangled_names) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1}({2}) is skipped", GetSymbolFileName(),
__FUNCTION__, scope_qualified_name);
return;
}
return m_sym_file_impl->GetMangledNamesForFunction(scope_qualified_name,
mangled_names);
}
[lldb] Make only one function that needs to be implemented when searching for types (#74786) This patch revives the effort to get this Phabricator patch into upstream: https://reviews.llvm.org/D137900 This patch was accepted before in Phabricator but I found some -gsimple-template-names issues that are fixed in this patch. A fixed up version of the description from the original patch starts now. This patch started off trying to fix Module::FindFirstType() as it sometimes didn't work. The issue was the SymbolFile plug-ins didn't do any filtering of the matching types they produced, and they only looked up types using the type basename. This means if you have two types with the same basename, your type lookup can fail when only looking up a single type. We would ask the Module::FindFirstType to lookup "Foo::Bar" and it would ask the symbol file to find only 1 type matching the basename "Bar", and then we would filter out any matches that didn't match "Foo::Bar". So if the SymbolFile found "Foo::Bar" first, then it would work, but if it found "Baz::Bar" first, it would return only that type and it would be filtered out. Discovering this issue lead me to think of the patch Alex Langford did a few months ago that was done for finding functions, where he allowed SymbolFile objects to make sure something fully matched before parsing the debug information into an AST type and other LLDB types. So this patch aimed to allow type lookups to also be much more efficient. As LLDB has been developed over the years, we added more ways to to type lookups. These functions have lots of arguments. This patch aims to make one API that needs to be implemented that serves all previous lookups: - Find a single type - Find all types - Find types in a namespace This patch introduces a `TypeQuery` class that contains all of the state needed to perform the lookup which is powerful enough to perform all of the type searches that used to be in our API. It contain a vector of CompilerContext objects that can fully or partially specify the lookup that needs to take place. If you just want to lookup all types with a matching basename, regardless of the containing context, you can specify just a single CompilerContext entry that has a name and a CompilerContextKind mask of CompilerContextKind::AnyType. Or you can fully specify the exact context to use when doing lookups like: CompilerContextKind::Namespace "std" CompilerContextKind::Class "foo" CompilerContextKind::Typedef "size_type" This change expands on the clang modules code that already used a vector<CompilerContext> items, but it modifies it to work with expression type lookups which have contexts, or user lookups where users query for types. The clang modules type lookup is still an option that can be enabled on the `TypeQuery` objects. This mirrors the most recent addition of type lookups that took a vector<CompilerContext> that allowed lookups to happen for the expression parser in certain places. Prior to this we had the following APIs in Module: ``` void Module::FindTypes(ConstString type_name, bool exact_match, size_t max_matches, llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files, TypeList &types); void Module::FindTypes(llvm::ArrayRef<CompilerContext> pattern, LanguageSet languages, llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files, TypeMap &types); void Module::FindTypesInNamespace(ConstString type_name, const CompilerDeclContext &parent_decl_ctx, size_t max_matches, TypeList &type_list); ``` The new Module API is much simpler. It gets rid of all three above functions and replaces them with: ``` void FindTypes(const TypeQuery &query, TypeResults &results); ``` The `TypeQuery` class contains all of the needed settings: - The vector<CompilerContext> that allow efficient lookups in the symbol file classes since they can look at basename matches only realize fully matching types. Before this any basename that matched was fully realized only to be removed later by code outside of the SymbolFile layer which could cause many types to be realized when they didn't need to. - If the lookup is exact or not. If not exact, then the compiler context must match the bottom most items that match the compiler context, otherwise it must match exactly - If the compiler context match is for clang modules or not. Clang modules matches include a Module compiler context kind that allows types to be matched only from certain modules and these matches are not needed when d oing user type lookups. - An optional list of languages to use to limit the search to only certain languages The `TypeResults` object contains all state required to do the lookup and store the results: - The max number of matches - The set of SymbolFile objects that have already been searched - The matching type list for any matches that are found The benefits of this approach are: - Simpler API, and only one API to implement in SymbolFile classes - Replaces the FindTypesInNamespace that used a CompilerDeclContext as a way to limit the search, but this only worked if the TypeSystem matched the current symbol file's type system, so you couldn't use it to lookup a type in another module - Fixes a serious bug in our FindFirstType functions where if we were searching for "foo::bar", and we found a "baz::bar" first, the basename would match and we would only fetch 1 type using the basename, only to drop it from the matching list and returning no results
2023-12-12 16:51:49 -08:00
void SymbolFileOnDemand::FindTypes(const TypeQuery &match,
TypeResults &results) {
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return;
}
[lldb] Make only one function that needs to be implemented when searching for types (#74786) This patch revives the effort to get this Phabricator patch into upstream: https://reviews.llvm.org/D137900 This patch was accepted before in Phabricator but I found some -gsimple-template-names issues that are fixed in this patch. A fixed up version of the description from the original patch starts now. This patch started off trying to fix Module::FindFirstType() as it sometimes didn't work. The issue was the SymbolFile plug-ins didn't do any filtering of the matching types they produced, and they only looked up types using the type basename. This means if you have two types with the same basename, your type lookup can fail when only looking up a single type. We would ask the Module::FindFirstType to lookup "Foo::Bar" and it would ask the symbol file to find only 1 type matching the basename "Bar", and then we would filter out any matches that didn't match "Foo::Bar". So if the SymbolFile found "Foo::Bar" first, then it would work, but if it found "Baz::Bar" first, it would return only that type and it would be filtered out. Discovering this issue lead me to think of the patch Alex Langford did a few months ago that was done for finding functions, where he allowed SymbolFile objects to make sure something fully matched before parsing the debug information into an AST type and other LLDB types. So this patch aimed to allow type lookups to also be much more efficient. As LLDB has been developed over the years, we added more ways to to type lookups. These functions have lots of arguments. This patch aims to make one API that needs to be implemented that serves all previous lookups: - Find a single type - Find all types - Find types in a namespace This patch introduces a `TypeQuery` class that contains all of the state needed to perform the lookup which is powerful enough to perform all of the type searches that used to be in our API. It contain a vector of CompilerContext objects that can fully or partially specify the lookup that needs to take place. If you just want to lookup all types with a matching basename, regardless of the containing context, you can specify just a single CompilerContext entry that has a name and a CompilerContextKind mask of CompilerContextKind::AnyType. Or you can fully specify the exact context to use when doing lookups like: CompilerContextKind::Namespace "std" CompilerContextKind::Class "foo" CompilerContextKind::Typedef "size_type" This change expands on the clang modules code that already used a vector<CompilerContext> items, but it modifies it to work with expression type lookups which have contexts, or user lookups where users query for types. The clang modules type lookup is still an option that can be enabled on the `TypeQuery` objects. This mirrors the most recent addition of type lookups that took a vector<CompilerContext> that allowed lookups to happen for the expression parser in certain places. Prior to this we had the following APIs in Module: ``` void Module::FindTypes(ConstString type_name, bool exact_match, size_t max_matches, llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files, TypeList &types); void Module::FindTypes(llvm::ArrayRef<CompilerContext> pattern, LanguageSet languages, llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files, TypeMap &types); void Module::FindTypesInNamespace(ConstString type_name, const CompilerDeclContext &parent_decl_ctx, size_t max_matches, TypeList &type_list); ``` The new Module API is much simpler. It gets rid of all three above functions and replaces them with: ``` void FindTypes(const TypeQuery &query, TypeResults &results); ``` The `TypeQuery` class contains all of the needed settings: - The vector<CompilerContext> that allow efficient lookups in the symbol file classes since they can look at basename matches only realize fully matching types. Before this any basename that matched was fully realized only to be removed later by code outside of the SymbolFile layer which could cause many types to be realized when they didn't need to. - If the lookup is exact or not. If not exact, then the compiler context must match the bottom most items that match the compiler context, otherwise it must match exactly - If the compiler context match is for clang modules or not. Clang modules matches include a Module compiler context kind that allows types to be matched only from certain modules and these matches are not needed when d oing user type lookups. - An optional list of languages to use to limit the search to only certain languages The `TypeResults` object contains all state required to do the lookup and store the results: - The max number of matches - The set of SymbolFile objects that have already been searched - The matching type list for any matches that are found The benefits of this approach are: - Simpler API, and only one API to implement in SymbolFile classes - Replaces the FindTypesInNamespace that used a CompilerDeclContext as a way to limit the search, but this only worked if the TypeSystem matched the current symbol file's type system, so you couldn't use it to lookup a type in another module - Fixes a serious bug in our FindFirstType functions where if we were searching for "foo::bar", and we found a "baz::bar" first, the basename would match and we would only fetch 1 type using the basename, only to drop it from the matching list and returning no results
2023-12-12 16:51:49 -08:00
return m_sym_file_impl->FindTypes(match, results);
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
}
void SymbolFileOnDemand::GetTypes(SymbolContextScope *sc_scope,
TypeClass type_mask, TypeList &type_list) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return;
}
return m_sym_file_impl->GetTypes(sc_scope, type_mask, type_list);
}
llvm::Expected<lldb::TypeSystemSP>
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
SymbolFileOnDemand::GetTypeSystemForLanguage(LanguageType language) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped for language type {2}",
GetSymbolFileName(), __FUNCTION__, language);
return llvm::createStringError(
"GetTypeSystemForLanguage is skipped by SymbolFileOnDemand");
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
}
return m_sym_file_impl->GetTypeSystemForLanguage(language);
}
CompilerDeclContext
SymbolFileOnDemand::FindNamespace(ConstString name,
const CompilerDeclContext &parent_decl_ctx,
bool only_root_namespaces) {
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1}({2}) is skipped", GetSymbolFileName(),
__FUNCTION__, name);
return SymbolFile::FindNamespace(name, parent_decl_ctx,
only_root_namespaces);
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
}
return m_sym_file_impl->FindNamespace(name, parent_decl_ctx,
only_root_namespaces);
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
}
std::vector<std::unique_ptr<lldb_private::CallEdge>>
SymbolFileOnDemand::ParseCallEdgesInFunction(UserID func_id) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped", GetSymbolFileName(), __FUNCTION__);
if (log) {
std::vector<std::unique_ptr<lldb_private::CallEdge>> call_edges =
m_sym_file_impl->ParseCallEdgesInFunction(func_id);
if (call_edges.size() > 0) {
LLDB_LOG(log, "{0} call edges would be parsed for {1} if hydrated.",
call_edges.size(), func_id.GetID());
}
}
return {};
}
return m_sym_file_impl->ParseCallEdgesInFunction(func_id);
}
lldb::UnwindPlanSP
SymbolFileOnDemand::GetUnwindPlan(const Address &address,
const RegisterInfoResolver &resolver) {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return nullptr;
}
return m_sym_file_impl->GetUnwindPlan(address, resolver);
}
llvm::Expected<lldb::addr_t>
SymbolFileOnDemand::GetParameterStackSize(Symbol &symbol) {
if (!m_debug_info_enabled) {
Log *log = GetLog();
LLDB_LOG(log, "[{0}] {1} is skipped", GetSymbolFileName(), __FUNCTION__);
if (log) {
llvm::Expected<lldb::addr_t> stack_size =
m_sym_file_impl->GetParameterStackSize(symbol);
if (stack_size) {
LLDB_LOG(log, "{0} stack size would return for symbol {1} if hydrated.",
*stack_size, symbol.GetName());
}
}
return SymbolFile::GetParameterStackSize(symbol);
}
return m_sym_file_impl->GetParameterStackSize(symbol);
}
void SymbolFileOnDemand::PreloadSymbols() {
m_preload_symbols = true;
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return;
}
return m_sym_file_impl->PreloadSymbols();
}
uint64_t SymbolFileOnDemand::GetDebugInfoSize(bool load_all_debug_info) {
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
// Always return the real debug info size.
LLDB_LOG(GetLog(), "[{0}] {1} is not skipped", GetSymbolFileName(),
__FUNCTION__);
return m_sym_file_impl->GetDebugInfoSize(load_all_debug_info);
Introduce new symbol on-demand for debug info This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-20 07:30:53 -07:00
}
StatsDuration::Duration SymbolFileOnDemand::GetDebugInfoParseTime() {
// Always return the real parse time.
LLDB_LOG(GetLog(), "[{0}] {1} is not skipped", GetSymbolFileName(),
__FUNCTION__);
return m_sym_file_impl->GetDebugInfoParseTime();
}
StatsDuration::Duration SymbolFileOnDemand::GetDebugInfoIndexTime() {
// Always return the real index time.
LLDB_LOG(GetLog(), "[{0}] {1} is not skipped", GetSymbolFileName(),
__FUNCTION__);
return m_sym_file_impl->GetDebugInfoIndexTime();
}
void SymbolFileOnDemand::SetLoadDebugInfoEnabled() {
if (m_debug_info_enabled)
return;
LLDB_LOG(GetLog(), "[{0}] Hydrate debug info", GetSymbolFileName());
m_debug_info_enabled = true;
InitializeObject();
if (m_preload_symbols)
PreloadSymbols();
}
uint32_t SymbolFileOnDemand::GetNumCompileUnits() {
LLDB_LOG(GetLog(), "[{0}] {1} is not skipped to support breakpoint hydration",
GetSymbolFileName(), __FUNCTION__);
return m_sym_file_impl->GetNumCompileUnits();
}
CompUnitSP SymbolFileOnDemand::GetCompileUnitAtIndex(uint32_t idx) {
LLDB_LOG(GetLog(), "[{0}] {1} is not skipped to support breakpoint hydration",
GetSymbolFileName(), __FUNCTION__);
return m_sym_file_impl->GetCompileUnitAtIndex(idx);
}
uint32_t SymbolFileOnDemand::GetAbilities() {
if (!m_debug_info_enabled) {
LLDB_LOG(GetLog(), "[{0}] {1} is skipped", GetSymbolFileName(),
__FUNCTION__);
return 0;
}
return m_sym_file_impl->GetAbilities();
}