[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
|
|
|
//===-- CompileUnit.cpp ---------------------------------------------------===//
|
2010-06-09 00:52:24 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08: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
|
2010-06-09 00:52:24 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#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"
|
2019-08-06 17:12:42 +08:00
|
|
|
#include "lldb/Symbol/SymbolFile.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Symbol/VariableList.h"
|
2015-09-02 09:06:46 +08:00
|
|
|
#include "lldb/Target/Language.h"
|
2019-11-13 03:23:38 +08:00
|
|
|
#include "lldb/Utility/Timer.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2016-07-06 07:01:20 +08:00
|
|
|
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)
|
2019-11-28 23:22:44 +08:00
|
|
|
: CompileUnit(module_sp, user_data, FileSpec(pathname), cu_sym_id, language,
|
|
|
|
is_optimized) {}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-07-06 07:01:20 +08:00
|
|
|
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)
|
2019-11-28 23:22:44 +08:00
|
|
|
: ModuleChild(module_sp), UserID(cu_sym_id), m_user_data(user_data),
|
|
|
|
m_language(language), m_flags(0), m_file_spec(fspec),
|
2016-07-06 07:01:20 +08:00
|
|
|
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);
|
2012-02-24 09:59:29 +08:00
|
|
|
assert(module_sp);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void CompileUnit::CalculateSymbolContext(SymbolContext *sc) {
|
|
|
|
sc->comp_unit = this;
|
|
|
|
GetModule()->CalculateSymbolContext(sc);
|
|
|
|
}
|
|
|
|
|
2011-08-13 05:40:01 +08:00
|
|
|
ModuleSP CompileUnit::CalculateSymbolContextModule() { return GetModule(); }
|
|
|
|
|
|
|
|
CompileUnit *CompileUnit::CalculateSymbolContextCompileUnit() { return this; }
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
void CompileUnit::DumpSymbolContext(Stream *s) {
|
|
|
|
GetModule()->DumpSymbolContext(s);
|
2012-11-30 05:49:15 +08:00
|
|
|
s->Printf(", CompileUnit{0x%8.8" PRIx64 "}", GetID());
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2010-06-29 05:30:43 +08:00
|
|
|
void CompileUnit::GetDescription(Stream *s,
|
|
|
|
lldb::DescriptionLevel level) const {
|
2015-09-02 09:06:46 +08:00
|
|
|
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 = \""
|
2019-11-28 23:22:44 +08:00
|
|
|
<< this->GetPrimaryFile() << "\", language = \"" << language << '"';
|
2010-06-29 05:30:43 +08:00
|
|
|
}
|
|
|
|
|
2018-08-12 07:40:27 +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);
|
2019-01-09 07:25:06 +08:00
|
|
|
llvm::sort(sorted_functions.begin(), sorted_functions.end(),
|
|
|
|
[](const lldb::FunctionSP &a, const lldb::FunctionSP &b) {
|
|
|
|
return a->GetID() < b->GetID();
|
|
|
|
});
|
2018-08-12 07:40:27 +08:00
|
|
|
|
|
|
|
for (auto &f : sorted_functions)
|
|
|
|
if (lambda(f))
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-11-13 03:23:38 +08:00
|
|
|
lldb::FunctionSP CompileUnit::FindFunction(
|
|
|
|
llvm::function_ref<bool(const FunctionSP &)> matching_lambda) {
|
2020-12-22 05:41:57 +08:00
|
|
|
LLDB_SCOPED_TIMER();
|
2019-11-13 03:23:38 +08:00
|
|
|
|
|
|
|
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 {};
|
|
|
|
}
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// 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.
|
2010-06-09 00:52:24 +08:00
|
|
|
void CompileUnit::Dump(Stream *s, bool show_context) const {
|
2015-09-02 09:06:46 +08:00
|
|
|
const char *language = Language::GetNameForLanguageType(m_language);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2014-04-04 12:06:10 +08:00
|
|
|
s->Printf("%p: ", static_cast<const void *>(this));
|
2010-06-09 00:52:24 +08:00
|
|
|
s->Indent();
|
2014-04-04 12:06:10 +08:00
|
|
|
*s << "CompileUnit" << static_cast<const UserID &>(*this) << ", language = \""
|
2019-11-28 23:22:44 +08:00
|
|
|
<< language << "\", file = '" << GetPrimaryFile() << "'\n";
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
// m_types.Dump(s);
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
if (m_variables.get()) {
|
|
|
|
s->IndentMore();
|
|
|
|
m_variables->Dump(s, show_context);
|
|
|
|
s->IndentLess();
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2018-08-12 07:40:27 +08:00
|
|
|
if (!m_functions_by_uid.empty()) {
|
2010-06-09 00:52:24 +08:00
|
|
|
s->IndentMore();
|
2018-08-12 07:40:27 +08:00
|
|
|
ForeachFunction([&s, show_context](const FunctionSP &f) {
|
|
|
|
f->Dump(s, show_context);
|
|
|
|
return false;
|
|
|
|
});
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
s->IndentLess();
|
|
|
|
s->EOL();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add a function to this compile unit
|
|
|
|
void CompileUnit::AddFunction(FunctionSP &funcSP) {
|
2018-08-12 07:40:27 +08:00
|
|
|
m_functions_by_uid[funcSP->GetID()] = funcSP;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
FunctionSP CompileUnit::FindFunctionByUID(lldb::user_id_t func_uid) {
|
2018-08-12 07:40:27 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
lldb::LanguageType CompileUnit::GetLanguage() {
|
2014-04-20 21:17:36 +08:00
|
|
|
if (m_language == eLanguageTypeUnknown) {
|
2010-06-09 00:52:24 +08:00
|
|
|
if (m_flags.IsClear(flagsParsedLanguage)) {
|
|
|
|
m_flags.Set(flagsParsedLanguage);
|
2019-08-06 17:12:42 +08:00
|
|
|
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
|
|
|
|
m_language = symfile->ParseLanguage(*this);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
return m_language;
|
|
|
|
}
|
|
|
|
|
|
|
|
LineTable *CompileUnit::GetLineTable() {
|
2019-02-13 14:25:41 +08:00
|
|
|
if (m_line_table_up == nullptr) {
|
2010-06-09 00:52:24 +08:00
|
|
|
if (m_flags.IsClear(flagsParsedLineTable)) {
|
|
|
|
m_flags.Set(flagsParsedLineTable);
|
2019-08-06 17:12:42 +08:00
|
|
|
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
|
|
|
|
symfile->ParseLineTable(*this);
|
2015-12-16 08:22:08 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2019-02-13 14:25:41 +08:00
|
|
|
return m_line_table_up.get();
|
2015-12-16 08:22:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void CompileUnit::SetLineTable(LineTable *line_table) {
|
|
|
|
if (line_table == nullptr)
|
|
|
|
m_flags.Clear(flagsParsedLineTable);
|
|
|
|
else
|
|
|
|
m_flags.Set(flagsParsedLineTable);
|
2019-02-13 14:25:41 +08:00
|
|
|
m_line_table_up.reset(line_table);
|
2015-12-16 08:22:08 +08:00
|
|
|
}
|
|
|
|
|
2019-08-14 03:51:51 +08:00
|
|
|
void CompileUnit::SetSupportFiles(const FileSpecList &support_files) {
|
|
|
|
m_support_files = support_files;
|
|
|
|
}
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
DebugMacros *CompileUnit::GetDebugMacros() {
|
2014-04-20 21:17:36 +08:00
|
|
|
if (m_debug_macros_sp.get() == nullptr) {
|
|
|
|
if (m_flags.IsClear(flagsParsedDebugMacros)) {
|
2015-12-16 08:22:08 +08:00
|
|
|
m_flags.Set(flagsParsedDebugMacros);
|
2019-08-06 17:12:42 +08:00
|
|
|
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
|
|
|
|
symfile->ParseDebugMacros(*this);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
return m_debug_macros_sp.get();
|
|
|
|
}
|
|
|
|
|
2011-09-23 08:54:11 +08:00
|
|
|
void CompileUnit::SetDebugMacros(const DebugMacrosSP &debug_macros_sp) {
|
|
|
|
if (debug_macros_sp.get() == nullptr)
|
2010-06-09 00:52:24 +08:00
|
|
|
m_flags.Clear(flagsParsedDebugMacros);
|
|
|
|
else
|
2011-09-23 08:54:11 +08:00
|
|
|
m_flags.Set(flagsParsedDebugMacros);
|
|
|
|
m_debug_macros_sp = debug_macros_sp;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
VariableListSP CompileUnit::GetVariableList(bool can_create) {
|
2015-12-16 08:22:08 +08:00
|
|
|
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);
|
2010-06-09 00:52:24 +08:00
|
|
|
assert(sc.module_sp);
|
2019-08-06 17:12:42 +08:00
|
|
|
sc.module_sp->GetSymbolFile()->ParseVariablesForContext(sc);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
|
|
|
return m_variables;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
[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;
|
|
|
|
}
|
|
|
|
|
2011-09-23 08:54:11 +08:00
|
|
|
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;
|
|
|
|
|
2021-05-05 07:03:10 +08:00
|
|
|
// TODO: Handle SourceLocationSpec column information
|
|
|
|
SourceLocationSpec location_spec(*file_spec_ptr, line, /*column=*/llvm::None,
|
|
|
|
/*check_inlines=*/false, exact);
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
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(
|
2021-05-05 07:03:10 +08:00
|
|
|
start_idx, file_indexes, location_spec, line_entry_ptr);
|
2010-06-09 00:52:24 +08:00
|
|
|
return UINT32_MAX;
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2021-05-05 07:03:10 +08:00
|
|
|
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();
|
|
|
|
|
2010-09-12 14:24:05 +08:00
|
|
|
// First find all of the file indexes that match our "file_spec". If
|
2018-05-01 00:49:04 +08:00
|
|
|
// "file_spec" has an empty directory, then only compare the basenames when
|
|
|
|
// finding file indexes
|
2010-09-12 14:24:05 +08:00
|
|
|
std::vector<uint32_t> file_indexes;
|
2014-11-15 09:54:26 +08:00
|
|
|
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());
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-09-12 14:24:05 +08:00
|
|
|
// If we are not looking for inlined functions and our file spec doesn't
|
|
|
|
// match then we are done...
|
2018-12-15 08:15:33 +08:00
|
|
|
if (!file_spec_matches_cu_file_spec && !check_inlines)
|
2019-11-28 23:54:15 +08:00
|
|
|
return;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2021-03-19 04:32:39 +08:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2014-11-15 09:54:26 +08:00
|
|
|
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);
|
2010-09-12 14:24:05 +08:00
|
|
|
while (file_idx != UINT32_MAX) {
|
|
|
|
file_indexes.push_back(file_idx);
|
2018-04-27 23:45:58 +08:00
|
|
|
file_idx = GetSupportFiles().FindFileIndex(file_idx + 1, file_spec, true);
|
2010-09-12 14:24:05 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2010-09-12 14:24:05 +08:00
|
|
|
const size_t num_file_indexes = file_indexes.size();
|
|
|
|
if (num_file_indexes == 0)
|
2019-11-28 23:54:15 +08:00
|
|
|
return;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2021-03-19 04:32:39 +08:00
|
|
|
LineTable *line_table = sc.comp_unit->GetLineTable();
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2021-03-19 04:32:39 +08:00
|
|
|
if (line_table == nullptr) {
|
2019-11-28 23:54:15 +08:00
|
|
|
if (file_spec_matches_cu_file_spec && !check_inlines) {
|
|
|
|
sc_list.Append(sc);
|
2019-11-28 21:25:46 +08:00
|
|
|
}
|
2019-11-28 23:54:15 +08:00
|
|
|
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(
|
2021-05-05 07:03:10 +08:00
|
|
|
0, file_indexes.front(), src_location_spec, &line_entry);
|
2019-11-28 23:54:15 +08:00
|
|
|
} 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.
|
2021-05-05 07:03:10 +08:00
|
|
|
line_idx = line_table->FindLineEntryIndexByFileIndex(
|
|
|
|
0, file_indexes, src_location_spec, &line_entry);
|
2019-11-28 23:54:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// 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.
|
2021-05-05 07:03:10 +08:00
|
|
|
const bool inlines = false;
|
|
|
|
const bool exact = true;
|
|
|
|
SourceLocationSpec found_entry(line_entry.file, line_entry.line,
|
|
|
|
line_entry.column, inlines, exact);
|
|
|
|
|
2019-11-28 23:54:15 +08:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2010-09-12 14:24:05 +08:00
|
|
|
sc_list.Append(sc);
|
2019-11-28 23:54:15 +08:00
|
|
|
if (num_file_indexes == 1)
|
|
|
|
line_idx = line_table->FindLineEntryIndexByFileIndex(
|
2021-05-05 07:03:10 +08:00
|
|
|
line_idx + 1, file_indexes.front(), found_entry, &line_entry);
|
2019-11-28 23:54:15 +08:00
|
|
|
else
|
|
|
|
line_idx = line_table->FindLineEntryIndexByFileIndex(
|
2021-05-05 07:03:10 +08:00
|
|
|
line_idx + 1, file_indexes, found_entry, &line_entry);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-29 08:42:47 +08:00
|
|
|
bool CompileUnit::GetIsOptimized() {
|
2016-07-06 07:01:20 +08:00
|
|
|
if (m_is_optimized == eLazyBoolCalculate) {
|
|
|
|
m_is_optimized = eLazyBoolNo;
|
2019-08-06 17:12:42 +08:00
|
|
|
if (SymbolFile *symfile = GetModule()->GetSymbolFile()) {
|
|
|
|
if (symfile->ParseIsOptimized(*this))
|
2016-07-06 07:01:20 +08:00
|
|
|
m_is_optimized = eLazyBoolYes;
|
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-07-29 08:42:47 +08:00
|
|
|
return m_is_optimized;
|
|
|
|
}
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
void CompileUnit::SetVariableList(VariableListSP &variables) {
|
|
|
|
m_variables = variables;
|
|
|
|
}
|
|
|
|
|
2019-02-14 02:10:41 +08:00
|
|
|
const std::vector<SourceModule> &CompileUnit::GetImportedModules() {
|
2015-04-21 00:31:29 +08:00
|
|
|
if (m_imported_modules.empty() &&
|
|
|
|
m_flags.IsClear(flagsParsedImportedModules)) {
|
|
|
|
m_flags.Set(flagsParsedImportedModules);
|
2019-08-06 17:12:42 +08:00
|
|
|
if (SymbolFile *symfile = GetModule()->GetSymbolFile()) {
|
2015-04-21 00:31:29 +08:00
|
|
|
SymbolContext sc;
|
|
|
|
CalculateSymbolContext(&sc);
|
2019-08-06 17:12:42 +08:00
|
|
|
symfile->ParseImportedModules(sc, m_imported_modules);
|
2015-04-21 00:31:29 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2015-04-21 00:31:29 +08:00
|
|
|
return m_imported_modules;
|
|
|
|
}
|
|
|
|
|
2019-11-15 00:57:32 +08:00
|
|
|
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())
|
2019-11-15 00:57:32 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2019-05-30 16:21:25 +08:00
|
|
|
const FileSpecList &CompileUnit::GetSupportFiles() {
|
2010-06-09 00:52:24 +08:00
|
|
|
if (m_support_files.GetSize() == 0) {
|
|
|
|
if (m_flags.IsClear(flagsParsedSupportFiles)) {
|
|
|
|
m_flags.Set(flagsParsedSupportFiles);
|
2019-08-06 17:12:42 +08:00
|
|
|
if (SymbolFile *symfile = GetModule()->GetSymbolFile())
|
|
|
|
symfile->ParseSupportFiles(*this, m_support_files);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
return m_support_files;
|
|
|
|
}
|
|
|
|
|
|
|
|
void *CompileUnit::GetUserData() const { return m_user_data; }
|