llvm-project/lldb/source/Symbol/CompileUnit.cpp

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

384 lines
13 KiB
C++
Raw Normal View History

//===-- CompileUnit.cpp ---------------------------------------------------===//
//
// 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/CompileUnit.h"
#include "lldb/Core/Module.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Symbol/LineTable.h"
#include "lldb/Symbol/SymbolFile.h"
#include "lldb/Symbol/VariableList.h"
#include "lldb/Target/Language.h"
#include "lldb/Utility/Timer.h"
using namespace lldb;
using namespace lldb_private;
CompileUnit::CompileUnit(const lldb::ModuleSP &module_sp, void *user_data,
const char *pathname, const lldb::user_id_t cu_sym_id,
lldb::LanguageType language,
lldb_private::LazyBool is_optimized)
: CompileUnit(module_sp, user_data, FileSpec(pathname), cu_sym_id, language,
is_optimized) {}
CompileUnit::CompileUnit(const lldb::ModuleSP &module_sp, void *user_data,
const FileSpec &fspec, const lldb::user_id_t cu_sym_id,
lldb::LanguageType language,
lldb_private::LazyBool is_optimized)
: ModuleChild(module_sp), UserID(cu_sym_id), m_user_data(user_data),
m_language(language), m_flags(0), m_file_spec(fspec),
m_is_optimized(is_optimized) {
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
if (language != eLanguageTypeUnknown)
m_flags.Set(flagsParsedLanguage);
assert(module_sp);
}
void CompileUnit::CalculateSymbolContext(SymbolContext *sc) {
sc->comp_unit = this;
GetModule()->CalculateSymbolContext(sc);
}
ModuleSP CompileUnit::CalculateSymbolContextModule() { return GetModule(); }
CompileUnit *CompileUnit::CalculateSymbolContextCompileUnit() { return this; }
void CompileUnit::DumpSymbolContext(Stream *s) {
GetModule()->DumpSymbolContext(s);
s->Printf(", CompileUnit{0x%8.8" PRIx64 "}", GetID());
}
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
void CompileUnit::GetDescription(Stream *s,
lldb::DescriptionLevel level) const {
const char *language = Language::GetNameForLanguageType(m_language);
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
*s << "id = " << (const UserID &)*this << ", file = \""
<< this->GetPrimaryFile() << "\", language = \"" << language << '"';
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
}
void CompileUnit::ForeachFunction(
llvm::function_ref<bool(const FunctionSP &)> lambda) const {
std::vector<lldb::FunctionSP> sorted_functions;
sorted_functions.reserve(m_functions_by_uid.size());
for (auto &p : m_functions_by_uid)
sorted_functions.push_back(p.second);
llvm::sort(sorted_functions.begin(), sorted_functions.end(),
[](const lldb::FunctionSP &a, const lldb::FunctionSP &b) {
return a->GetID() < b->GetID();
});
for (auto &f : sorted_functions)
if (lambda(f))
return;
}
lldb::FunctionSP CompileUnit::FindFunction(
llvm::function_ref<bool(const FunctionSP &)> matching_lambda) {
LLDB_SCOPED_TIMER();
lldb::ModuleSP module = CalculateSymbolContextModule();
if (!module)
return {};
SymbolFile *symbol_file = module->GetSymbolFile();
if (!symbol_file)
return {};
// m_functions_by_uid is filled in lazily but we need all the entries.
symbol_file->ParseFunctions(*this);
for (auto &p : m_functions_by_uid) {
if (matching_lambda(p.second))
return p.second;
}
return {};
}
// Dump the current contents of this object. No functions that cause on demand
// parsing of functions, globals, statics are called, so this is a good
// function to call to get an idea of the current contents of the CompileUnit
// object.
void CompileUnit::Dump(Stream *s, bool show_context) const {
const char *language = Language::GetNameForLanguageType(m_language);
s->Printf("%p: ", static_cast<const void *>(this));
s->Indent();
*s << "CompileUnit" << static_cast<const UserID &>(*this) << ", language = \""
<< language << "\", file = '" << GetPrimaryFile() << "'\n";
// m_types.Dump(s);
if (m_variables.get()) {
s->IndentMore();
m_variables->Dump(s, show_context);
s->IndentLess();
}
if (!m_functions_by_uid.empty()) {
s->IndentMore();
ForeachFunction([&s, show_context](const FunctionSP &f) {
f->Dump(s, show_context);
return false;
});
s->IndentLess();
s->EOL();
}
}
// Add a function to this compile unit
void CompileUnit::AddFunction(FunctionSP &funcSP) {
m_functions_by_uid[funcSP->GetID()] = funcSP;
}
FunctionSP CompileUnit::FindFunctionByUID(lldb::user_id_t func_uid) {
auto it = m_functions_by_uid.find(func_uid);
if (it == m_functions_by_uid.end())
return FunctionSP();
return it->second;
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
}
lldb::LanguageType CompileUnit::GetLanguage() {
if (m_language == eLanguageTypeUnknown) {
if (m_flags.IsClear(flagsParsedLanguage)) {
m_flags.Set(flagsParsedLanguage);
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
m_language = symfile->ParseLanguage(*this);
}
}
return m_language;
}
LineTable *CompileUnit::GetLineTable() {
if (m_line_table_up == nullptr) {
if (m_flags.IsClear(flagsParsedLineTable)) {
m_flags.Set(flagsParsedLineTable);
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
symfile->ParseLineTable(*this);
}
}
return m_line_table_up.get();
}
void CompileUnit::SetLineTable(LineTable *line_table) {
if (line_table == nullptr)
m_flags.Clear(flagsParsedLineTable);
else
m_flags.Set(flagsParsedLineTable);
m_line_table_up.reset(line_table);
}
void CompileUnit::SetSupportFiles(const FileSpecList &support_files) {
m_support_files = support_files;
}
DebugMacros *CompileUnit::GetDebugMacros() {
if (m_debug_macros_sp.get() == nullptr) {
if (m_flags.IsClear(flagsParsedDebugMacros)) {
m_flags.Set(flagsParsedDebugMacros);
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
symfile->ParseDebugMacros(*this);
}
}
return m_debug_macros_sp.get();
}
void CompileUnit::SetDebugMacros(const DebugMacrosSP &debug_macros_sp) {
if (debug_macros_sp.get() == nullptr)
m_flags.Clear(flagsParsedDebugMacros);
else
m_flags.Set(flagsParsedDebugMacros);
m_debug_macros_sp = debug_macros_sp;
}
VariableListSP CompileUnit::GetVariableList(bool can_create) {
if (m_variables.get() == nullptr && can_create) {
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
SymbolContext sc;
CalculateSymbolContext(&sc);
assert(sc.module_sp);
sc.module_sp->GetSymbolFile()->ParseVariablesForContext(sc);
}
return m_variables;
}
[lldb] Don't put compile unit name into the support file list and support DWARF5 line tables Summary: Lldb's "format-independent" debug info made use of the fact that DWARF (<=4) did not use the file index zero, and reused the support file index zero for storing the compile unit name. While this provided some convenience for DWARF<=4, it meant that the PDB plugin needed to artificially remap file indices in order to free up index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that similar remapping would be needed in the dwarf plugin too. What this patch does instead is remove the requirement of having the compile unit name in the index 0. It is not that useful since the name can always be fetched from the CompileUnit object. Remapping code in the pdb plugin(s) has been removed or simplified. DWARF plugin has started inserting an empty FileSpec at index 0 to ensure the indices keep matching up (in case of DWARF<=4). For DWARF5, we insert the file 0 from the line table. I add a test to ensure we can correctly lookup line table entries referencing file 0, and in particular the case where the file 0 is also duplicated in another file entry, as this is how clang produces line tables in some circumstances (see pr44170). Though this is probably a bug in clang, this is not forbidden by DWARF, and lldb already has support for that in some (but not all) cases -- this adds a test for the code path which was not fixed in this patch. Reviewers: clayborg, JDevlieghere, jdoerfert Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70954
2019-11-28 17:19:23 +08:00
std::vector<uint32_t> FindFileIndexes(const FileSpecList &files, const FileSpec &file) {
std::vector<uint32_t> result;
uint32_t idx = -1;
while ((idx = files.FindFileIndex(idx + 1, file, /*full=*/true)) !=
UINT32_MAX)
result.push_back(idx);
return result;
}
uint32_t CompileUnit::FindLineEntry(uint32_t start_idx, uint32_t line,
const FileSpec *file_spec_ptr, bool exact,
LineEntry *line_entry_ptr) {
[lldb] Don't put compile unit name into the support file list and support DWARF5 line tables Summary: Lldb's "format-independent" debug info made use of the fact that DWARF (<=4) did not use the file index zero, and reused the support file index zero for storing the compile unit name. While this provided some convenience for DWARF<=4, it meant that the PDB plugin needed to artificially remap file indices in order to free up index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that similar remapping would be needed in the dwarf plugin too. What this patch does instead is remove the requirement of having the compile unit name in the index 0. It is not that useful since the name can always be fetched from the CompileUnit object. Remapping code in the pdb plugin(s) has been removed or simplified. DWARF plugin has started inserting an empty FileSpec at index 0 to ensure the indices keep matching up (in case of DWARF<=4). For DWARF5, we insert the file 0 from the line table. I add a test to ensure we can correctly lookup line table entries referencing file 0, and in particular the case where the file 0 is also duplicated in another file entry, as this is how clang produces line tables in some circumstances (see pr44170). Though this is probably a bug in clang, this is not forbidden by DWARF, and lldb already has support for that in some (but not all) cases -- this adds a test for the code path which was not fixed in this patch. Reviewers: clayborg, JDevlieghere, jdoerfert Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70954
2019-11-28 17:19:23 +08:00
if (!file_spec_ptr)
file_spec_ptr = &GetPrimaryFile();
std::vector<uint32_t> file_indexes = FindFileIndexes(GetSupportFiles(), *file_spec_ptr);
if (file_indexes.empty())
return UINT32_MAX;
// TODO: Handle SourceLocationSpec column information
SourceLocationSpec location_spec(*file_spec_ptr, line, /*column=*/llvm::None,
/*check_inlines=*/false, exact);
LineTable *line_table = GetLineTable();
if (line_table)
[lldb] Don't put compile unit name into the support file list and support DWARF5 line tables Summary: Lldb's "format-independent" debug info made use of the fact that DWARF (<=4) did not use the file index zero, and reused the support file index zero for storing the compile unit name. While this provided some convenience for DWARF<=4, it meant that the PDB plugin needed to artificially remap file indices in order to free up index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that similar remapping would be needed in the dwarf plugin too. What this patch does instead is remove the requirement of having the compile unit name in the index 0. It is not that useful since the name can always be fetched from the CompileUnit object. Remapping code in the pdb plugin(s) has been removed or simplified. DWARF plugin has started inserting an empty FileSpec at index 0 to ensure the indices keep matching up (in case of DWARF<=4). For DWARF5, we insert the file 0 from the line table. I add a test to ensure we can correctly lookup line table entries referencing file 0, and in particular the case where the file 0 is also duplicated in another file entry, as this is how clang produces line tables in some circumstances (see pr44170). Though this is probably a bug in clang, this is not forbidden by DWARF, and lldb already has support for that in some (but not all) cases -- this adds a test for the code path which was not fixed in this patch. Reviewers: clayborg, JDevlieghere, jdoerfert Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70954
2019-11-28 17:19:23 +08:00
return line_table->FindLineEntryIndexByFileIndex(
start_idx, file_indexes, location_spec, line_entry_ptr);
return UINT32_MAX;
}
void CompileUnit::ResolveSymbolContext(
const SourceLocationSpec &src_location_spec,
SymbolContextItem resolve_scope, SymbolContextList &sc_list) {
const FileSpec file_spec = src_location_spec.GetFileSpec();
const uint32_t line = src_location_spec.GetLine().getValueOr(0);
const bool check_inlines = src_location_spec.GetCheckInlines();
// First find all of the file indexes that match our "file_spec". If
// "file_spec" has an empty directory, then only compare the basenames when
// finding file indexes
std::vector<uint32_t> file_indexes;
bool file_spec_matches_cu_file_spec =
[lldb] s/FileSpec::Equal/FileSpec::Match Summary: The FileSpec class is often used as a sort of a pattern -- one specifies a bare file name to search, and we check if in matches the full file name of an existing module (for example). These comparisons used FileSpec::Equal, which had some support for it (via the full=false argument), but it was not a good fit for this job. For one, it did a symmetric comparison, which makes sense for a function called "equal", but not for typical searches (when searching for "/foo/bar.so", we don't want to find a module whose name is just "bar.so"). This resulted in patterns like: if (FileSpec::Equal(pattern, file, pattern.GetDirectory())) which would request a "full" match only if the pattern really contained a directory. This worked, but the intended behavior was very unobvious. On top of that, a lot of the code wanted to handle the case of an "empty" pattern, and treat it as matching everything. This resulted in conditions like: if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory()) which are nearly impossible to decipher. This patch introduces a FileSpec::Match function, which does exactly what most of FileSpec::Equal callers want, an asymmetric match between a "pattern" FileSpec and a an actual FileSpec. Empty paterns match everything, filename-only patterns match only the filename component. I've tried to update all callers of FileSpec::Equal to use a simpler interface. Those that hardcoded full=true have been changed to use operator==. Those passing full=pattern.GetDirectory() have been changed to use FileSpec::Match. There was also a handful of places which hardcoded full=false. I've changed these to use FileSpec::Match too. This is a slight change in semantics, but it does not look like that was ever intended, and it was more likely a result of a misunderstanding of the "proper" way to use FileSpec::Equal. [In an ideal world a "FileSpec" and a "FileSpec pattern" would be two different types, but given how widespread FileSpec is, it is unlikely we'll get there in one go. This at least provides a good starting point by centralizing all matching behavior.] Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: emaste, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70851
2019-11-29 18:31:00 +08:00
FileSpec::Match(file_spec, this->GetPrimaryFile());
// If we are not looking for inlined functions and our file spec doesn't
// match then we are done...
if (!file_spec_matches_cu_file_spec && !check_inlines)
return;
SymbolContext sc(GetModule());
sc.comp_unit = this;
if (line == 0) {
if (file_spec_matches_cu_file_spec && !check_inlines) {
// only append the context if we aren't looking for inline call sites by
// file and line and if the file spec matches that of the compile unit
sc_list.Append(sc);
}
return;
}
uint32_t file_idx =
[lldb] Don't put compile unit name into the support file list and support DWARF5 line tables Summary: Lldb's "format-independent" debug info made use of the fact that DWARF (<=4) did not use the file index zero, and reused the support file index zero for storing the compile unit name. While this provided some convenience for DWARF<=4, it meant that the PDB plugin needed to artificially remap file indices in order to free up index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that similar remapping would be needed in the dwarf plugin too. What this patch does instead is remove the requirement of having the compile unit name in the index 0. It is not that useful since the name can always be fetched from the CompileUnit object. Remapping code in the pdb plugin(s) has been removed or simplified. DWARF plugin has started inserting an empty FileSpec at index 0 to ensure the indices keep matching up (in case of DWARF<=4). For DWARF5, we insert the file 0 from the line table. I add a test to ensure we can correctly lookup line table entries referencing file 0, and in particular the case where the file 0 is also duplicated in another file entry, as this is how clang produces line tables in some circumstances (see pr44170). Though this is probably a bug in clang, this is not forbidden by DWARF, and lldb already has support for that in some (but not all) cases -- this adds a test for the code path which was not fixed in this patch. Reviewers: clayborg, JDevlieghere, jdoerfert Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70954
2019-11-28 17:19:23 +08:00
GetSupportFiles().FindFileIndex(0, file_spec, true);
while (file_idx != UINT32_MAX) {
file_indexes.push_back(file_idx);
file_idx = GetSupportFiles().FindFileIndex(file_idx + 1, file_spec, true);
}
const size_t num_file_indexes = file_indexes.size();
if (num_file_indexes == 0)
return;
LineTable *line_table = sc.comp_unit->GetLineTable();
if (line_table == nullptr) {
if (file_spec_matches_cu_file_spec && !check_inlines) {
sc_list.Append(sc);
}
return;
}
uint32_t line_idx;
LineEntry line_entry;
if (num_file_indexes == 1) {
// We only have a single support file that matches, so use the line
// table function that searches for a line entries that match a single
// support file index
line_idx = line_table->FindLineEntryIndexByFileIndex(
0, file_indexes.front(), src_location_spec, &line_entry);
} else {
// We found multiple support files that match "file_spec" so use the
// line table function that searches for a line entries that match a
// multiple support file indexes.
line_idx = line_table->FindLineEntryIndexByFileIndex(
0, file_indexes, src_location_spec, &line_entry);
}
// If "exact == true", then "found_line" will be the same as "line". If
// "exact == false", the "found_line" will be the closest line entry
// with a line number greater than "line" and we will use this for our
// subsequent line exact matches below.
const bool inlines = false;
const bool exact = true;
SourceLocationSpec found_entry(line_entry.file, line_entry.line,
line_entry.column, inlines, exact);
while (line_idx != UINT32_MAX) {
// If they only asked for the line entry, then we're done, we can
// just copy that over. But if they wanted more than just the line
// number, fill it in.
if (resolve_scope == eSymbolContextLineEntry) {
sc.line_entry = line_entry;
} else {
line_entry.range.GetBaseAddress().CalculateSymbolContext(&sc,
resolve_scope);
}
sc_list.Append(sc);
if (num_file_indexes == 1)
line_idx = line_table->FindLineEntryIndexByFileIndex(
line_idx + 1, file_indexes.front(), found_entry, &line_entry);
else
line_idx = line_table->FindLineEntryIndexByFileIndex(
line_idx + 1, file_indexes, found_entry, &line_entry);
}
}
bool CompileUnit::GetIsOptimized() {
if (m_is_optimized == eLazyBoolCalculate) {
m_is_optimized = eLazyBoolNo;
if (SymbolFile *symfile = GetModule()->GetSymbolFile()) {
if (symfile->ParseIsOptimized(*this))
m_is_optimized = eLazyBoolYes;
}
}
return m_is_optimized;
}
void CompileUnit::SetVariableList(VariableListSP &variables) {
m_variables = variables;
}
const std::vector<SourceModule> &CompileUnit::GetImportedModules() {
if (m_imported_modules.empty() &&
m_flags.IsClear(flagsParsedImportedModules)) {
m_flags.Set(flagsParsedImportedModules);
if (SymbolFile *symfile = GetModule()->GetSymbolFile()) {
SymbolContext sc;
CalculateSymbolContext(&sc);
symfile->ParseImportedModules(sc, m_imported_modules);
}
}
return m_imported_modules;
}
bool CompileUnit::ForEachExternalModule(
llvm::DenseSet<SymbolFile *> &visited_symbol_files,
llvm::function_ref<bool(Module &)> lambda) {
[lldb] Decouple importing the std C++ module from the way the program is compiled Summary: At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to cause a few problems or inconveniences: * It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default (and we can't just close all the associated bug reports). * Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux). * We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS). This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit. If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the `Darwin` module are their own external type module with their own files). The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism), but for now it works and makes the feature usable. Reviewers: aprantl, shafik, jdoerfert Reviewed By: aprantl Subscribers: mgorny, abidh, JDevlieghere, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D67760 llvm-svn: 372716
2019-09-24 18:08:18 +08:00
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
return symfile->ForEachExternalModule(*this, visited_symbol_files, lambda);
return false;
[lldb] Decouple importing the std C++ module from the way the program is compiled Summary: At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to cause a few problems or inconveniences: * It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default (and we can't just close all the associated bug reports). * Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux). * We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS). This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit. If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the `Darwin` module are their own external type module with their own files). The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism), but for now it works and makes the feature usable. Reviewers: aprantl, shafik, jdoerfert Reviewed By: aprantl Subscribers: mgorny, abidh, JDevlieghere, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D67760 llvm-svn: 372716
2019-09-24 18:08:18 +08:00
}
const FileSpecList &CompileUnit::GetSupportFiles() {
if (m_support_files.GetSize() == 0) {
if (m_flags.IsClear(flagsParsedSupportFiles)) {
m_flags.Set(flagsParsedSupportFiles);
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
symfile->ParseSupportFiles(*this, m_support_files);
}
}
return m_support_files;
}
void *CompileUnit::GetUserData() const { return m_user_data; }