2010-06-09 00:52:24 +08:00
|
|
|
//===-- Symtab.cpp ----------------------------------------------*- C++ -*-===//
|
|
|
|
//
|
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 <map>
|
2015-09-02 09:59:14 +08:00
|
|
|
#include <set>
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
#include "Plugins/Language/ObjC/ObjCLanguage.h"
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Core/Module.h"
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
#include "lldb/Core/RichManglingContext.h"
|
2017-03-22 02:45:42 +08:00
|
|
|
#include "lldb/Core/STLUtils.h"
|
2017-06-29 22:32:17 +08:00
|
|
|
#include "lldb/Core/Section.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
2015-02-26 06:41:34 +08:00
|
|
|
#include "lldb/Symbol/Symbol.h"
|
2013-01-08 08:01:36 +08:00
|
|
|
#include "lldb/Symbol/SymbolContext.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
#include "lldb/Symbol/Symtab.h"
|
2017-02-03 05:39:50 +08:00
|
|
|
#include "lldb/Utility/RegularExpression.h"
|
|
|
|
#include "lldb/Utility/Stream.h"
|
2017-06-29 22:32:17 +08:00
|
|
|
#include "lldb/Utility/Timer.h"
|
2010-06-09 00:52:24 +08:00
|
|
|
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
|
2010-06-09 00:52:24 +08:00
|
|
|
using namespace lldb;
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
2016-05-19 13:13:57 +08:00
|
|
|
Symtab::Symtab(ObjectFile *objfile)
|
2016-09-07 04:57:50 +08:00
|
|
|
: m_objfile(objfile), m_symbols(), m_file_addr_to_index(),
|
|
|
|
m_name_to_index(), m_mutex(), m_file_addr_to_index_computed(false),
|
|
|
|
m_name_indexes_computed(false) {}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Symtab::~Symtab() {}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::Reserve(size_t count) {
|
|
|
|
// Clients should grab the mutex from this symbol table and lock it manually
|
|
|
|
// when calling this function to avoid performance issues.
|
|
|
|
m_symbols.reserve(count);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Symbol *Symtab::Resize(size_t count) {
|
|
|
|
// Clients should grab the mutex from this symbol table and lock it manually
|
|
|
|
// when calling this function to avoid performance issues.
|
|
|
|
m_symbols.resize(count);
|
|
|
|
return m_symbols.empty() ? nullptr : &m_symbols[0];
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Symtab::AddSymbol(const Symbol &symbol) {
|
|
|
|
// Clients should grab the mutex from this symbol table and lock it manually
|
|
|
|
// when calling this function to avoid performance issues.
|
|
|
|
uint32_t symbol_idx = m_symbols.size();
|
|
|
|
m_name_to_index.Clear();
|
|
|
|
m_file_addr_to_index.Clear();
|
|
|
|
m_symbols.push_back(symbol);
|
|
|
|
m_file_addr_to_index_computed = false;
|
|
|
|
m_name_indexes_computed = false;
|
|
|
|
return symbol_idx;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
size_t Symtab::GetNumSymbols() const {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
return m_symbols.size();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::SectionFileAddressesChanged() {
|
|
|
|
m_name_to_index.Clear();
|
|
|
|
m_file_addr_to_index_computed = false;
|
2014-08-22 10:46:46 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::Dump(Stream *s, Target *target, SortOrder sort_order) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
|
|
|
// s->Printf("%.*p: ", (int)sizeof(void*) * 2, this);
|
|
|
|
s->Indent();
|
|
|
|
const FileSpec &file_spec = m_objfile->GetFileSpec();
|
|
|
|
const char *object_name = nullptr;
|
|
|
|
if (m_objfile->GetModule())
|
|
|
|
object_name = m_objfile->GetModule()->GetObjectName().GetCString();
|
|
|
|
|
|
|
|
if (file_spec)
|
|
|
|
s->Printf("Symtab, file = %s%s%s%s, num_symbols = %" PRIu64,
|
|
|
|
file_spec.GetPath().c_str(), object_name ? "(" : "",
|
|
|
|
object_name ? object_name : "", object_name ? ")" : "",
|
|
|
|
(uint64_t)m_symbols.size());
|
|
|
|
else
|
|
|
|
s->Printf("Symtab, num_symbols = %" PRIu64 "", (uint64_t)m_symbols.size());
|
|
|
|
|
|
|
|
if (!m_symbols.empty()) {
|
|
|
|
switch (sort_order) {
|
|
|
|
case eSortOrderNone: {
|
|
|
|
s->PutCString(":\n");
|
|
|
|
DumpSymbolHeader(s);
|
|
|
|
const_iterator begin = m_symbols.begin();
|
|
|
|
const_iterator end = m_symbols.end();
|
|
|
|
for (const_iterator pos = m_symbols.begin(); pos != end; ++pos) {
|
|
|
|
s->Indent();
|
|
|
|
pos->Dump(s, target, std::distance(begin, pos));
|
|
|
|
}
|
|
|
|
} break;
|
|
|
|
|
|
|
|
case eSortOrderByName: {
|
2018-05-01 00:49:04 +08:00
|
|
|
// Although we maintain a lookup by exact name map, the table isn't
|
|
|
|
// sorted by name. So we must make the ordered symbol list up ourselves.
|
2016-09-07 04:57:50 +08:00
|
|
|
s->PutCString(" (sorted by name):\n");
|
|
|
|
DumpSymbolHeader(s);
|
|
|
|
typedef std::multimap<const char *, const Symbol *,
|
|
|
|
CStringCompareFunctionObject>
|
|
|
|
CStringToSymbol;
|
|
|
|
CStringToSymbol name_map;
|
|
|
|
for (const_iterator pos = m_symbols.begin(), end = m_symbols.end();
|
|
|
|
pos != end; ++pos) {
|
|
|
|
const char *name = pos->GetName().AsCString();
|
|
|
|
if (name && name[0])
|
|
|
|
name_map.insert(std::make_pair(name, &(*pos)));
|
|
|
|
}
|
|
|
|
|
|
|
|
for (CStringToSymbol::const_iterator pos = name_map.begin(),
|
|
|
|
end = name_map.end();
|
|
|
|
pos != end; ++pos) {
|
|
|
|
s->Indent();
|
|
|
|
pos->second->Dump(s, target, pos->second - &m_symbols[0]);
|
|
|
|
}
|
|
|
|
} break;
|
|
|
|
|
|
|
|
case eSortOrderByAddress:
|
|
|
|
s->PutCString(" (sorted by address):\n");
|
|
|
|
DumpSymbolHeader(s);
|
|
|
|
if (!m_file_addr_to_index_computed)
|
|
|
|
InitAddressIndexes();
|
|
|
|
const size_t num_entries = m_file_addr_to_index.GetSize();
|
|
|
|
for (size_t i = 0; i < num_entries; ++i) {
|
|
|
|
s->Indent();
|
|
|
|
const uint32_t symbol_idx = m_file_addr_to_index.GetEntryRef(i).data;
|
|
|
|
m_symbols[symbol_idx].Dump(s, target, symbol_idx);
|
|
|
|
}
|
|
|
|
break;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2018-10-02 01:08:51 +08:00
|
|
|
} else {
|
|
|
|
s->PutCString("\n");
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::Dump(Stream *s, Target *target,
|
|
|
|
std::vector<uint32_t> &indexes) const {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
|
|
|
const size_t num_symbols = GetNumSymbols();
|
|
|
|
// s->Printf("%.*p: ", (int)sizeof(void*) * 2, this);
|
|
|
|
s->Indent();
|
|
|
|
s->Printf("Symtab %" PRIu64 " symbol indexes (%" PRIu64 " symbols total):\n",
|
|
|
|
(uint64_t)indexes.size(), (uint64_t)m_symbols.size());
|
|
|
|
s->IndentMore();
|
|
|
|
|
|
|
|
if (!indexes.empty()) {
|
|
|
|
std::vector<uint32_t>::const_iterator pos;
|
|
|
|
std::vector<uint32_t>::const_iterator end = indexes.end();
|
|
|
|
DumpSymbolHeader(s);
|
|
|
|
for (pos = indexes.begin(); pos != end; ++pos) {
|
|
|
|
size_t idx = *pos;
|
|
|
|
if (idx < num_symbols) {
|
|
|
|
s->Indent();
|
|
|
|
m_symbols[idx].Dump(s, target, idx);
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
s->IndentLess();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::DumpSymbolHeader(Stream *s) {
|
|
|
|
s->Indent(" Debug symbol\n");
|
|
|
|
s->Indent(" |Synthetic symbol\n");
|
|
|
|
s->Indent(" ||Externally Visible\n");
|
|
|
|
s->Indent(" |||\n");
|
|
|
|
s->Indent("Index UserID DSX Type File Address/Value Load "
|
|
|
|
"Address Size Flags Name\n");
|
|
|
|
s->Indent("------- ------ --- --------------- ------------------ "
|
|
|
|
"------------------ ------------------ ---------- "
|
|
|
|
"----------------------------------\n");
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
static int CompareSymbolID(const void *key, const void *p) {
|
|
|
|
const user_id_t match_uid = *(const user_id_t *)key;
|
|
|
|
const user_id_t symbol_uid = ((const Symbol *)p)->GetID();
|
|
|
|
if (match_uid < symbol_uid)
|
|
|
|
return -1;
|
|
|
|
if (match_uid > symbol_uid)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
2010-09-08 01:36:17 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Symbol *Symtab::FindSymbolByID(lldb::user_id_t symbol_uid) const {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Symbol *symbol =
|
|
|
|
(Symbol *)::bsearch(&symbol_uid, &m_symbols[0], m_symbols.size(),
|
|
|
|
sizeof(m_symbols[0]), CompareSymbolID);
|
|
|
|
return symbol;
|
2010-09-08 01:36:17 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Symbol *Symtab::SymbolAtIndex(size_t idx) {
|
|
|
|
// Clients should grab the mutex from this symbol table and lock it manually
|
|
|
|
// when calling this function to avoid performance issues.
|
|
|
|
if (idx < m_symbols.size())
|
|
|
|
return &m_symbols[idx];
|
|
|
|
return nullptr;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const Symbol *Symtab::SymbolAtIndex(size_t idx) const {
|
|
|
|
// Clients should grab the mutex from this symbol table and lock it manually
|
|
|
|
// when calling this function to avoid performance issues.
|
|
|
|
if (idx < m_symbols.size())
|
|
|
|
return &m_symbols[idx];
|
|
|
|
return nullptr;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// InitNameIndexes
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
static bool lldb_skip_name(llvm::StringRef mangled,
|
|
|
|
Mangled::ManglingScheme scheme) {
|
|
|
|
switch (scheme) {
|
|
|
|
case Mangled::eManglingSchemeItanium: {
|
|
|
|
if (mangled.size() < 3 || !mangled.startswith("_Z"))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Avoid the following types of symbols in the index.
|
|
|
|
switch (mangled[2]) {
|
|
|
|
case 'G': // guard variables
|
|
|
|
case 'T': // virtual tables, VTT structures, typeinfo structures + names
|
|
|
|
case 'Z': // named local entities (if we eventually handle
|
|
|
|
// eSymbolTypeData, we will want this back)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Include this name in the index.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// No filters for this scheme yet. Include all names in indexing.
|
|
|
|
case Mangled::eManglingSchemeMSVC:
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Don't try and demangle things we can't categorize.
|
|
|
|
case Mangled::eManglingSchemeNone:
|
|
|
|
return true;
|
|
|
|
}
|
2018-09-03 20:57:54 +08:00
|
|
|
llvm_unreachable("unknown scheme!");
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::InitNameIndexes() {
|
|
|
|
// Protected function, no need to lock mutex...
|
|
|
|
if (!m_name_indexes_computed) {
|
|
|
|
m_name_indexes_computed = true;
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
|
2016-09-07 04:57:50 +08:00
|
|
|
// Create the name index vector to be able to quickly search by name
|
|
|
|
const size_t num_symbols = m_symbols.size();
|
2010-10-08 12:20:14 +08:00
|
|
|
#if 1
|
2016-09-07 04:57:50 +08:00
|
|
|
m_name_to_index.Reserve(num_symbols);
|
2010-10-08 12:20:14 +08:00
|
|
|
#else
|
2016-09-07 04:57:50 +08:00
|
|
|
// TODO: benchmark this to see if we save any memory. Otherwise we
|
2018-05-01 00:49:04 +08:00
|
|
|
// will always keep the memory reserved in the vector unless we pull some
|
|
|
|
// STL swap magic and then recopy...
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t actual_count = 0;
|
|
|
|
for (const_iterator pos = m_symbols.begin(), end = m_symbols.end();
|
|
|
|
pos != end; ++pos) {
|
|
|
|
const Mangled &mangled = pos->GetMangled();
|
|
|
|
if (mangled.GetMangledName())
|
|
|
|
++actual_count;
|
|
|
|
|
|
|
|
if (mangled.GetDemangledName())
|
|
|
|
++actual_count;
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
m_name_to_index.Reserve(actual_count);
|
2010-10-08 12:20:14 +08:00
|
|
|
#endif
|
2010-06-09 00:52:24 +08:00
|
|
|
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
// The "const char *" in "class_contexts" and backlog::value_type::second
|
|
|
|
// must come from a ConstString::GetCString()
|
2016-09-07 04:57:50 +08:00
|
|
|
std::set<const char *> class_contexts;
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
std::vector<std::pair<NameToIndexMap::Entry, const char *>> backlog;
|
|
|
|
backlog.reserve(num_symbols / 2);
|
|
|
|
|
|
|
|
// Instantiation of the demangler is expensive, so better use a single one
|
|
|
|
// for all entries during batch processing.
|
|
|
|
RichManglingContext rmc;
|
|
|
|
NameToIndexMap::Entry entry;
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
for (entry.value = 0; entry.value < num_symbols; ++entry.value) {
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
Symbol *symbol = &m_symbols[entry.value];
|
2016-09-07 04:57:50 +08:00
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// Don't let trampolines get into the lookup by name map If we ever need
|
|
|
|
// the trampoline symbols to be searchable by name we can remove this and
|
|
|
|
// then possibly add a new bool to any of the Symtab functions that
|
|
|
|
// lookup symbols by name to indicate if they want trampolines.
|
2016-09-07 04:57:50 +08:00
|
|
|
if (symbol->IsTrampoline())
|
|
|
|
continue;
|
|
|
|
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
// If the symbol's name string matched a Mangled::ManglingScheme, it is
|
|
|
|
// stored in the mangled field.
|
|
|
|
Mangled &mangled = symbol->GetMangled();
|
2017-05-02 18:17:30 +08:00
|
|
|
entry.cstring = mangled.GetMangledName();
|
|
|
|
if (entry.cstring) {
|
2016-09-07 04:57:50 +08:00
|
|
|
m_name_to_index.Append(entry);
|
|
|
|
|
|
|
|
if (symbol->ContainsLinkerAnnotations()) {
|
|
|
|
// If the symbol has linker annotations, also add the version without
|
2016-10-07 05:22:44 +08:00
|
|
|
// the annotations.
|
2016-09-07 04:57:50 +08:00
|
|
|
entry.cstring = ConstString(m_objfile->StripLinkerSymbolAnnotations(
|
2017-05-02 18:17:30 +08:00
|
|
|
entry.cstring.GetStringRef()));
|
2016-09-07 04:57:50 +08:00
|
|
|
m_name_to_index.Append(entry);
|
|
|
|
}
|
2015-03-04 18:25:22 +08:00
|
|
|
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
const SymbolType type = symbol->GetType();
|
|
|
|
if (type == eSymbolTypeCode || type == eSymbolTypeResolver) {
|
|
|
|
if (mangled.DemangleWithRichManglingInfo(rmc, lldb_skip_name))
|
|
|
|
RegisterMangledNameEntry(entry, class_contexts, backlog, rmc);
|
2010-10-08 12:20:14 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
// Symbol name strings that didn't match a Mangled::ManglingScheme, are
|
|
|
|
// stored in the demangled field.
|
2017-05-02 18:17:30 +08:00
|
|
|
entry.cstring = mangled.GetDemangledName(symbol->GetLanguage());
|
|
|
|
if (entry.cstring) {
|
2016-09-07 04:57:50 +08:00
|
|
|
m_name_to_index.Append(entry);
|
|
|
|
|
|
|
|
if (symbol->ContainsLinkerAnnotations()) {
|
|
|
|
// If the symbol has linker annotations, also add the version without
|
2016-10-07 05:22:44 +08:00
|
|
|
// the annotations.
|
2016-09-07 04:57:50 +08:00
|
|
|
entry.cstring = ConstString(m_objfile->StripLinkerSymbolAnnotations(
|
2017-05-02 18:17:30 +08:00
|
|
|
entry.cstring.GetStringRef()));
|
2016-09-07 04:57:50 +08:00
|
|
|
m_name_to_index.Append(entry);
|
2013-04-03 10:00:15 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// If the demangled name turns out to be an ObjC name, and is a category
|
|
|
|
// name, add the version without categories to the index too.
|
2017-05-02 18:17:30 +08:00
|
|
|
ObjCLanguage::MethodName objc_method(entry.cstring.GetStringRef(), true);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (objc_method.IsValid(true)) {
|
2017-05-02 18:17:30 +08:00
|
|
|
entry.cstring = objc_method.GetSelector();
|
2016-09-07 04:57:50 +08:00
|
|
|
m_selector_to_index.Append(entry);
|
|
|
|
|
|
|
|
ConstString objc_method_no_category(
|
|
|
|
objc_method.GetFullNameWithoutCategory(true));
|
|
|
|
if (objc_method_no_category) {
|
2017-05-02 18:17:30 +08:00
|
|
|
entry.cstring = objc_method_no_category;
|
2016-09-07 04:57:50 +08:00
|
|
|
m_name_to_index.Append(entry);
|
|
|
|
}
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
for (const auto &record : backlog) {
|
|
|
|
RegisterBacklogEntry(record.first, record.second, class_contexts);
|
2011-12-04 04:02:42 +08:00
|
|
|
}
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
m_name_to_index.Sort();
|
|
|
|
m_name_to_index.SizeToFit();
|
|
|
|
m_selector_to_index.Sort();
|
|
|
|
m_selector_to_index.SizeToFit();
|
|
|
|
m_basename_to_index.Sort();
|
|
|
|
m_basename_to_index.SizeToFit();
|
|
|
|
m_method_to_index.Sort();
|
|
|
|
m_method_to_index.SizeToFit();
|
|
|
|
}
|
2011-12-04 04:02:42 +08:00
|
|
|
}
|
|
|
|
|
Use rich mangling information in Symtab::InitNameIndexes()
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
2018-08-09 05:57:37 +08:00
|
|
|
void Symtab::RegisterMangledNameEntry(
|
|
|
|
NameToIndexMap::Entry &entry, std::set<const char *> &class_contexts,
|
|
|
|
std::vector<std::pair<NameToIndexMap::Entry, const char *>> &backlog,
|
|
|
|
RichManglingContext &rmc) {
|
|
|
|
// Only register functions that have a base name.
|
|
|
|
rmc.ParseFunctionBaseName();
|
|
|
|
llvm::StringRef base_name = rmc.GetBufferRef();
|
|
|
|
if (base_name.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// The base name will be our entry's name.
|
|
|
|
entry.cstring = ConstString(base_name);
|
|
|
|
|
|
|
|
rmc.ParseFunctionDeclContextName();
|
|
|
|
llvm::StringRef decl_context = rmc.GetBufferRef();
|
|
|
|
|
|
|
|
// Register functions with no context.
|
|
|
|
if (decl_context.empty()) {
|
|
|
|
// This has to be a basename
|
|
|
|
m_basename_to_index.Append(entry);
|
|
|
|
// If there is no context (no namespaces or class scopes that come before
|
|
|
|
// the function name) then this also could be a fullname.
|
|
|
|
m_name_to_index.Append(entry);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Make sure we have a pool-string pointer and see if we already know the
|
|
|
|
// context name.
|
|
|
|
const char *decl_context_ccstr = ConstString(decl_context).GetCString();
|
|
|
|
auto it = class_contexts.find(decl_context_ccstr);
|
|
|
|
|
|
|
|
// Register constructors and destructors. They are methods and create
|
|
|
|
// declaration contexts.
|
|
|
|
if (rmc.IsCtorOrDtor()) {
|
|
|
|
m_method_to_index.Append(entry);
|
|
|
|
if (it == class_contexts.end())
|
|
|
|
class_contexts.insert(it, decl_context_ccstr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Register regular methods with a known declaration context.
|
|
|
|
if (it != class_contexts.end()) {
|
|
|
|
m_method_to_index.Append(entry);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Regular methods in unknown declaration contexts are put to the backlog. We
|
|
|
|
// will revisit them once we processed all remaining symbols.
|
|
|
|
backlog.push_back(std::make_pair(entry, decl_context_ccstr));
|
|
|
|
}
|
|
|
|
|
|
|
|
void Symtab::RegisterBacklogEntry(
|
|
|
|
const NameToIndexMap::Entry &entry, const char *decl_context,
|
|
|
|
const std::set<const char *> &class_contexts) {
|
|
|
|
auto it = class_contexts.find(decl_context);
|
|
|
|
if (it != class_contexts.end()) {
|
|
|
|
m_method_to_index.Append(entry);
|
|
|
|
} else {
|
|
|
|
// If we got here, we have something that had a context (was inside
|
|
|
|
// a namespace or class) yet we don't know the entry
|
|
|
|
m_method_to_index.Append(entry);
|
|
|
|
m_basename_to_index.Append(entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-28 08:51:06 +08:00
|
|
|
void Symtab::PreloadSymbols() {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
InitNameIndexes();
|
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::AppendSymbolNamesToMap(const IndexCollection &indexes,
|
|
|
|
bool add_demangled, bool add_mangled,
|
|
|
|
NameToIndexMap &name_to_index_map) const {
|
|
|
|
if (add_demangled || add_mangled) {
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
|
2016-05-19 13:13:57 +08:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// Create the name index vector to be able to quickly search by name
|
|
|
|
NameToIndexMap::Entry entry;
|
|
|
|
const size_t num_indexes = indexes.size();
|
|
|
|
for (size_t i = 0; i < num_indexes; ++i) {
|
|
|
|
entry.value = indexes[i];
|
|
|
|
assert(i < m_symbols.size());
|
|
|
|
const Symbol *symbol = &m_symbols[entry.value];
|
|
|
|
|
|
|
|
const Mangled &mangled = symbol->GetMangled();
|
|
|
|
if (add_demangled) {
|
2017-05-02 18:17:30 +08:00
|
|
|
entry.cstring = mangled.GetDemangledName(symbol->GetLanguage());
|
|
|
|
if (entry.cstring)
|
2016-09-07 04:57:50 +08:00
|
|
|
name_to_index_map.Append(entry);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (add_mangled) {
|
2017-05-02 18:17:30 +08:00
|
|
|
entry.cstring = mangled.GetMangledName();
|
|
|
|
if (entry.cstring)
|
2016-09-07 04:57:50 +08:00
|
|
|
name_to_index_map.Append(entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Symtab::AppendSymbolIndexesWithType(SymbolType symbol_type,
|
|
|
|
std::vector<uint32_t> &indexes,
|
|
|
|
uint32_t start_idx,
|
|
|
|
uint32_t end_index) const {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t prev_size = indexes.size();
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const uint32_t count = std::min<uint32_t>(m_symbols.size(), end_index);
|
|
|
|
|
|
|
|
for (uint32_t i = start_idx; i < count; ++i) {
|
|
|
|
if (symbol_type == eSymbolTypeAny || m_symbols[i].GetType() == symbol_type)
|
|
|
|
indexes.push_back(i);
|
|
|
|
}
|
|
|
|
|
|
|
|
return indexes.size() - prev_size;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Symtab::AppendSymbolIndexesWithTypeAndFlagsValue(
|
|
|
|
SymbolType symbol_type, uint32_t flags_value,
|
|
|
|
std::vector<uint32_t> &indexes, uint32_t start_idx,
|
|
|
|
uint32_t end_index) const {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2011-01-20 14:08:59 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t prev_size = indexes.size();
|
2011-01-20 14:08:59 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const uint32_t count = std::min<uint32_t>(m_symbols.size(), end_index);
|
2011-01-20 14:08:59 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
for (uint32_t i = start_idx; i < count; ++i) {
|
|
|
|
if ((symbol_type == eSymbolTypeAny ||
|
|
|
|
m_symbols[i].GetType() == symbol_type) &&
|
|
|
|
m_symbols[i].GetFlags() == flags_value)
|
|
|
|
indexes.push_back(i);
|
|
|
|
}
|
2011-01-20 14:08:59 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return indexes.size() - prev_size;
|
2011-01-20 14:08:59 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Symtab::AppendSymbolIndexesWithType(SymbolType symbol_type,
|
|
|
|
Debug symbol_debug_type,
|
|
|
|
Visibility symbol_visibility,
|
|
|
|
std::vector<uint32_t> &indexes,
|
|
|
|
uint32_t start_idx,
|
|
|
|
uint32_t end_index) const {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t prev_size = indexes.size();
|
2010-09-11 11:13:28 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const uint32_t count = std::min<uint32_t>(m_symbols.size(), end_index);
|
2010-09-11 11:13:28 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
for (uint32_t i = start_idx; i < count; ++i) {
|
|
|
|
if (symbol_type == eSymbolTypeAny ||
|
|
|
|
m_symbols[i].GetType() == symbol_type) {
|
|
|
|
if (CheckSymbolAtIndex(i, symbol_debug_type, symbol_visibility))
|
|
|
|
indexes.push_back(i);
|
2010-09-11 11:13:28 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-09-11 11:13:28 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
return indexes.size() - prev_size;
|
2010-09-11 11:13:28 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Symtab::GetIndexForSymbol(const Symbol *symbol) const {
|
|
|
|
if (!m_symbols.empty()) {
|
|
|
|
const Symbol *first_symbol = &m_symbols[0];
|
|
|
|
if (symbol >= first_symbol && symbol < first_symbol + m_symbols.size())
|
|
|
|
return symbol - first_symbol;
|
|
|
|
}
|
|
|
|
return UINT32_MAX;
|
2010-09-11 11:13:28 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
struct SymbolSortInfo {
|
|
|
|
const bool sort_by_load_addr;
|
|
|
|
const Symbol *symbols;
|
2010-06-09 00:52:24 +08:00
|
|
|
};
|
|
|
|
|
2010-06-17 01:34:05 +08:00
|
|
|
namespace {
|
2016-09-07 04:57:50 +08:00
|
|
|
struct SymbolIndexComparator {
|
|
|
|
const std::vector<Symbol> &symbols;
|
|
|
|
std::vector<lldb::addr_t> &addr_cache;
|
|
|
|
|
|
|
|
// Getting from the symbol to the Address to the File Address involves some
|
2018-05-01 00:49:04 +08:00
|
|
|
// work. Since there are potentially many symbols here, and we're using this
|
|
|
|
// for sorting so we're going to be computing the address many times, cache
|
|
|
|
// that in addr_cache. The array passed in has to be the same size as the
|
|
|
|
// symbols array passed into the member variable symbols, and should be
|
|
|
|
// initialized with LLDB_INVALID_ADDRESS.
|
2016-09-07 04:57:50 +08:00
|
|
|
// NOTE: You have to make addr_cache externally and pass it in because
|
|
|
|
// std::stable_sort
|
|
|
|
// makes copies of the comparator it is initially passed in, and you end up
|
2018-05-01 00:49:04 +08:00
|
|
|
// spending huge amounts of time copying this array...
|
2016-09-07 04:57:50 +08:00
|
|
|
|
|
|
|
SymbolIndexComparator(const std::vector<Symbol> &s,
|
|
|
|
std::vector<lldb::addr_t> &a)
|
|
|
|
: symbols(s), addr_cache(a) {
|
|
|
|
assert(symbols.size() == addr_cache.size());
|
|
|
|
}
|
|
|
|
bool operator()(uint32_t index_a, uint32_t index_b) {
|
|
|
|
addr_t value_a = addr_cache[index_a];
|
|
|
|
if (value_a == LLDB_INVALID_ADDRESS) {
|
|
|
|
value_a = symbols[index_a].GetAddressRef().GetFileAddress();
|
|
|
|
addr_cache[index_a] = value_a;
|
|
|
|
}
|
2010-06-11 07:36:31 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
addr_t value_b = addr_cache[index_b];
|
|
|
|
if (value_b == LLDB_INVALID_ADDRESS) {
|
|
|
|
value_b = symbols[index_b].GetAddressRef().GetFileAddress();
|
|
|
|
addr_cache[index_b] = value_b;
|
|
|
|
}
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (value_a == value_b) {
|
|
|
|
// The if the values are equal, use the original symbol user ID
|
|
|
|
lldb::user_id_t uid_a = symbols[index_a].GetID();
|
|
|
|
lldb::user_id_t uid_b = symbols[index_b].GetID();
|
|
|
|
if (uid_a < uid_b)
|
|
|
|
return true;
|
|
|
|
if (uid_a > uid_b)
|
|
|
|
return false;
|
|
|
|
return false;
|
|
|
|
} else if (value_a < value_b)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
};
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::SortSymbolIndexesByValue(std::vector<uint32_t> &indexes,
|
|
|
|
bool remove_duplicates) const {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, LLVM_PRETTY_FUNCTION);
|
2016-09-07 04:57:50 +08:00
|
|
|
// No need to sort if we have zero or one items...
|
|
|
|
if (indexes.size() <= 1)
|
|
|
|
return;
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// Sort the indexes in place using std::stable_sort.
|
2019-01-09 07:25:06 +08:00
|
|
|
// NOTE: The use of std::stable_sort instead of llvm::sort here is strictly
|
|
|
|
// for performance, not correctness. The indexes vector tends to be "close"
|
|
|
|
// to sorted, which the stable sort handles better.
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
std::vector<lldb::addr_t> addr_cache(m_symbols.size(), LLDB_INVALID_ADDRESS);
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
SymbolIndexComparator comparator(m_symbols, addr_cache);
|
|
|
|
std::stable_sort(indexes.begin(), indexes.end(), comparator);
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// Remove any duplicates if requested
|
2017-08-01 09:29:55 +08:00
|
|
|
if (remove_duplicates) {
|
|
|
|
auto last = std::unique(indexes.begin(), indexes.end());
|
|
|
|
indexes.erase(last, indexes.end());
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2019-03-07 05:22:25 +08:00
|
|
|
uint32_t Symtab::AppendSymbolIndexesWithName(ConstString symbol_name,
|
2016-09-07 04:57:50 +08:00
|
|
|
std::vector<uint32_t> &indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (symbol_name) {
|
|
|
|
if (!m_name_indexes_computed)
|
|
|
|
InitNameIndexes();
|
|
|
|
|
2017-05-02 18:17:30 +08:00
|
|
|
return m_name_to_index.GetValues(symbol_name, indexes);
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return 0;
|
2010-09-11 11:13:28 +08:00
|
|
|
}
|
|
|
|
|
2019-03-07 05:22:25 +08:00
|
|
|
uint32_t Symtab::AppendSymbolIndexesWithName(ConstString symbol_name,
|
2016-09-07 04:57:50 +08:00
|
|
|
Debug symbol_debug_type,
|
|
|
|
Visibility symbol_visibility,
|
|
|
|
std::vector<uint32_t> &indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-09-11 11:13:28 +08:00
|
|
|
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (symbol_name) {
|
|
|
|
const size_t old_size = indexes.size();
|
|
|
|
if (!m_name_indexes_computed)
|
|
|
|
InitNameIndexes();
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
std::vector<uint32_t> all_name_indexes;
|
|
|
|
const size_t name_match_count =
|
2017-05-02 18:17:30 +08:00
|
|
|
m_name_to_index.GetValues(symbol_name, all_name_indexes);
|
2016-09-07 04:57:50 +08:00
|
|
|
for (size_t i = 0; i < name_match_count; ++i) {
|
|
|
|
if (CheckSymbolAtIndex(all_name_indexes[i], symbol_debug_type,
|
|
|
|
symbol_visibility))
|
|
|
|
indexes.push_back(all_name_indexes[i]);
|
|
|
|
}
|
|
|
|
return indexes.size() - old_size;
|
|
|
|
}
|
|
|
|
return 0;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2010-09-11 11:13:28 +08:00
|
|
|
uint32_t
|
2019-03-07 05:22:25 +08:00
|
|
|
Symtab::AppendSymbolIndexesWithNameAndType(ConstString symbol_name,
|
2016-09-07 04:57:50 +08:00
|
|
|
SymbolType symbol_type,
|
|
|
|
std::vector<uint32_t> &indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
|
|
|
if (AppendSymbolIndexesWithName(symbol_name, indexes) > 0) {
|
|
|
|
std::vector<uint32_t>::iterator pos = indexes.begin();
|
|
|
|
while (pos != indexes.end()) {
|
|
|
|
if (symbol_type == eSymbolTypeAny ||
|
|
|
|
m_symbols[*pos].GetType() == symbol_type)
|
|
|
|
++pos;
|
|
|
|
else
|
|
|
|
pos = indexes.erase(pos);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return indexes.size();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Symtab::AppendSymbolIndexesWithNameAndType(
|
2019-03-07 05:22:25 +08:00
|
|
|
ConstString symbol_name, SymbolType symbol_type,
|
2016-09-07 04:57:50 +08:00
|
|
|
Debug symbol_debug_type, Visibility symbol_visibility,
|
|
|
|
std::vector<uint32_t> &indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
|
|
|
if (AppendSymbolIndexesWithName(symbol_name, symbol_debug_type,
|
|
|
|
symbol_visibility, indexes) > 0) {
|
|
|
|
std::vector<uint32_t>::iterator pos = indexes.begin();
|
|
|
|
while (pos != indexes.end()) {
|
|
|
|
if (symbol_type == eSymbolTypeAny ||
|
|
|
|
m_symbols[*pos].GetType() == symbol_type)
|
|
|
|
++pos;
|
|
|
|
else
|
|
|
|
pos = indexes.erase(pos);
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return indexes.size();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Symtab::AppendSymbolIndexesMatchingRegExAndType(
|
|
|
|
const RegularExpression ®exp, SymbolType symbol_type,
|
|
|
|
std::vector<uint32_t> &indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
|
|
|
uint32_t prev_size = indexes.size();
|
|
|
|
uint32_t sym_end = m_symbols.size();
|
|
|
|
|
|
|
|
for (uint32_t i = 0; i < sym_end; i++) {
|
|
|
|
if (symbol_type == eSymbolTypeAny ||
|
|
|
|
m_symbols[i].GetType() == symbol_type) {
|
|
|
|
const char *name = m_symbols[i].GetName().AsCString();
|
|
|
|
if (name) {
|
|
|
|
if (regexp.Execute(name))
|
|
|
|
indexes.push_back(i);
|
|
|
|
}
|
2010-09-11 11:13:28 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return indexes.size() - prev_size;
|
2010-09-11 11:13:28 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t Symtab::AppendSymbolIndexesMatchingRegExAndType(
|
|
|
|
const RegularExpression ®exp, SymbolType symbol_type,
|
|
|
|
Debug symbol_debug_type, Visibility symbol_visibility,
|
|
|
|
std::vector<uint32_t> &indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
|
|
|
uint32_t prev_size = indexes.size();
|
|
|
|
uint32_t sym_end = m_symbols.size();
|
|
|
|
|
|
|
|
for (uint32_t i = 0; i < sym_end; i++) {
|
|
|
|
if (symbol_type == eSymbolTypeAny ||
|
|
|
|
m_symbols[i].GetType() == symbol_type) {
|
2018-12-15 08:15:33 +08:00
|
|
|
if (!CheckSymbolAtIndex(i, symbol_debug_type, symbol_visibility))
|
2016-09-07 04:57:50 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
const char *name = m_symbols[i].GetName().AsCString();
|
|
|
|
if (name) {
|
|
|
|
if (regexp.Execute(name))
|
|
|
|
indexes.push_back(i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return indexes.size() - prev_size;
|
|
|
|
}
|
2010-09-11 11:13:28 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Symbol *Symtab::FindSymbolWithType(SymbolType symbol_type,
|
|
|
|
Debug symbol_debug_type,
|
|
|
|
Visibility symbol_visibility,
|
|
|
|
uint32_t &start_idx) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
|
|
|
const size_t count = m_symbols.size();
|
|
|
|
for (size_t idx = start_idx; idx < count; ++idx) {
|
|
|
|
if (symbol_type == eSymbolTypeAny ||
|
|
|
|
m_symbols[idx].GetType() == symbol_type) {
|
|
|
|
if (CheckSymbolAtIndex(idx, symbol_debug_type, symbol_visibility)) {
|
|
|
|
start_idx = idx;
|
|
|
|
return &m_symbols[idx];
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return nullptr;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
size_t
|
2019-03-07 05:22:25 +08:00
|
|
|
Symtab::FindAllSymbolsWithNameAndType(ConstString name,
|
2016-09-07 04:57:50 +08:00
|
|
|
SymbolType symbol_type,
|
|
|
|
std::vector<uint32_t> &symbol_indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
|
2018-05-01 00:49:04 +08:00
|
|
|
// Initialize all of the lookup by name indexes before converting NAME to a
|
|
|
|
// uniqued string NAME_STR below.
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_name_indexes_computed)
|
|
|
|
InitNameIndexes();
|
|
|
|
|
|
|
|
if (name) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// The string table did have a string that matched, but we need to check
|
|
|
|
// the symbols and match the symbol_type if any was given.
|
2016-09-07 04:57:50 +08:00
|
|
|
AppendSymbolIndexesWithNameAndType(name, symbol_type, symbol_indexes);
|
|
|
|
}
|
|
|
|
return symbol_indexes.size();
|
|
|
|
}
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
size_t Symtab::FindAllSymbolsWithNameAndType(
|
2019-03-07 05:22:25 +08:00
|
|
|
ConstString name, SymbolType symbol_type, Debug symbol_debug_type,
|
2016-09-07 04:57:50 +08:00
|
|
|
Visibility symbol_visibility, std::vector<uint32_t> &symbol_indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
|
2018-05-01 00:49:04 +08:00
|
|
|
// Initialize all of the lookup by name indexes before converting NAME to a
|
|
|
|
// uniqued string NAME_STR below.
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_name_indexes_computed)
|
|
|
|
InitNameIndexes();
|
|
|
|
|
|
|
|
if (name) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// The string table did have a string that matched, but we need to check
|
|
|
|
// the symbols and match the symbol_type if any was given.
|
2016-09-07 04:57:50 +08:00
|
|
|
AppendSymbolIndexesWithNameAndType(name, symbol_type, symbol_debug_type,
|
|
|
|
symbol_visibility, symbol_indexes);
|
|
|
|
}
|
|
|
|
return symbol_indexes.size();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
size_t Symtab::FindAllSymbolsMatchingRexExAndType(
|
|
|
|
const RegularExpression ®ex, SymbolType symbol_type,
|
|
|
|
Debug symbol_debug_type, Visibility symbol_visibility,
|
|
|
|
std::vector<uint32_t> &symbol_indexes) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
AppendSymbolIndexesMatchingRegExAndType(regex, symbol_type, symbol_debug_type,
|
|
|
|
symbol_visibility, symbol_indexes);
|
|
|
|
return symbol_indexes.size();
|
|
|
|
}
|
|
|
|
|
2019-03-07 05:22:25 +08:00
|
|
|
Symbol *Symtab::FindFirstSymbolWithNameAndType(ConstString name,
|
2016-09-07 04:57:50 +08:00
|
|
|
SymbolType symbol_type,
|
|
|
|
Debug symbol_debug_type,
|
|
|
|
Visibility symbol_visibility) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
|
2017-05-15 21:02:37 +08:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
Timer scoped_timer(func_cat, "%s", LLVM_PRETTY_FUNCTION);
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_name_indexes_computed)
|
|
|
|
InitNameIndexes();
|
|
|
|
|
|
|
|
if (name) {
|
|
|
|
std::vector<uint32_t> matching_indexes;
|
2018-05-01 00:49:04 +08:00
|
|
|
// The string table did have a string that matched, but we need to check
|
|
|
|
// the symbols and match the symbol_type if any was given.
|
2016-09-07 04:57:50 +08:00
|
|
|
if (AppendSymbolIndexesWithNameAndType(name, symbol_type, symbol_debug_type,
|
|
|
|
symbol_visibility,
|
|
|
|
matching_indexes)) {
|
|
|
|
std::vector<uint32_t>::const_iterator pos, end = matching_indexes.end();
|
|
|
|
for (pos = matching_indexes.begin(); pos != end; ++pos) {
|
|
|
|
Symbol *symbol = SymbolAtIndex(*pos);
|
|
|
|
|
|
|
|
if (symbol->Compare(name, symbol_type))
|
|
|
|
return symbol;
|
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
return nullptr;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
typedef struct {
|
|
|
|
const Symtab *symtab;
|
|
|
|
const addr_t file_addr;
|
|
|
|
Symbol *match_symbol;
|
|
|
|
const uint32_t *match_index_ptr;
|
|
|
|
addr_t match_offset;
|
2010-06-09 00:52:24 +08:00
|
|
|
} SymbolSearchInfo;
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// Add all the section file start address & size to the RangeVector, recusively
|
|
|
|
// adding any children sections.
|
2016-09-07 04:57:50 +08:00
|
|
|
static void AddSectionsToRangeMap(SectionList *sectlist,
|
|
|
|
RangeVector<addr_t, addr_t> §ion_ranges) {
|
|
|
|
const int num_sections = sectlist->GetNumSections(0);
|
|
|
|
for (int i = 0; i < num_sections; i++) {
|
|
|
|
SectionSP sect_sp = sectlist->GetSectionAtIndex(i);
|
|
|
|
if (sect_sp) {
|
|
|
|
SectionList &child_sectlist = sect_sp->GetChildren();
|
|
|
|
|
|
|
|
// If this section has children, add the children to the RangeVector.
|
|
|
|
// Else add this section to the RangeVector.
|
|
|
|
if (child_sectlist.GetNumSections(0) > 0) {
|
|
|
|
AddSectionsToRangeMap(&child_sectlist, section_ranges);
|
|
|
|
} else {
|
|
|
|
size_t size = sect_sp->GetByteSize();
|
|
|
|
if (size > 0) {
|
|
|
|
addr_t base_addr = sect_sp->GetFileAddress();
|
|
|
|
RangeVector<addr_t, addr_t>::Entry entry;
|
|
|
|
entry.SetRangeBase(base_addr);
|
|
|
|
entry.SetByteSize(size);
|
|
|
|
section_ranges.Append(entry);
|
2016-04-13 12:32:49 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-04-13 12:32:49 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-04-13 12:32:49 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::InitAddressIndexes() {
|
|
|
|
// Protected function, no need to lock mutex...
|
|
|
|
if (!m_file_addr_to_index_computed && !m_symbols.empty()) {
|
|
|
|
m_file_addr_to_index_computed = true;
|
|
|
|
|
|
|
|
FileRangeToIndexMap::Entry entry;
|
|
|
|
const_iterator begin = m_symbols.begin();
|
|
|
|
const_iterator end = m_symbols.end();
|
|
|
|
for (const_iterator pos = m_symbols.begin(); pos != end; ++pos) {
|
|
|
|
if (pos->ValueIsAddress()) {
|
|
|
|
entry.SetRangeBase(pos->GetAddressRef().GetFileAddress());
|
|
|
|
entry.SetByteSize(pos->GetByteSize());
|
|
|
|
entry.data = std::distance(begin, pos);
|
|
|
|
m_file_addr_to_index.Append(entry);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
const size_t num_entries = m_file_addr_to_index.GetSize();
|
|
|
|
if (num_entries > 0) {
|
|
|
|
m_file_addr_to_index.Sort();
|
|
|
|
|
|
|
|
// Create a RangeVector with the start & size of all the sections for
|
|
|
|
// this objfile. We'll need to check this for any FileRangeToIndexMap
|
2018-05-01 00:49:04 +08:00
|
|
|
// entries with an uninitialized size, which could potentially be a large
|
|
|
|
// number so reconstituting the weak pointer is busywork when it is
|
|
|
|
// invariant information.
|
2016-09-07 04:57:50 +08:00
|
|
|
SectionList *sectlist = m_objfile->GetSectionList();
|
|
|
|
RangeVector<addr_t, addr_t> section_ranges;
|
|
|
|
if (sectlist) {
|
|
|
|
AddSectionsToRangeMap(sectlist, section_ranges);
|
|
|
|
section_ranges.Sort();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Iterate through the FileRangeToIndexMap and fill in the size for any
|
|
|
|
// entries that didn't already have a size from the Symbol (e.g. if we
|
|
|
|
// have a plain linker symbol with an address only, instead of debug info
|
|
|
|
// where we get an address and a size and a type, etc.)
|
|
|
|
for (size_t i = 0; i < num_entries; i++) {
|
|
|
|
FileRangeToIndexMap::Entry *entry =
|
|
|
|
m_file_addr_to_index.GetMutableEntryAtIndex(i);
|
|
|
|
if (entry->GetByteSize() == 0) {
|
|
|
|
addr_t curr_base_addr = entry->GetRangeBase();
|
|
|
|
const RangeVector<addr_t, addr_t>::Entry *containing_section =
|
|
|
|
section_ranges.FindEntryThatContains(curr_base_addr);
|
|
|
|
|
|
|
|
// Use the end of the section as the default max size of the symbol
|
|
|
|
addr_t sym_size = 0;
|
|
|
|
if (containing_section) {
|
|
|
|
sym_size =
|
|
|
|
containing_section->GetByteSize() -
|
|
|
|
(entry->GetRangeBase() - containing_section->GetRangeBase());
|
|
|
|
}
|
|
|
|
|
|
|
|
for (size_t j = i; j < num_entries; j++) {
|
|
|
|
FileRangeToIndexMap::Entry *next_entry =
|
|
|
|
m_file_addr_to_index.GetMutableEntryAtIndex(j);
|
|
|
|
addr_t next_base_addr = next_entry->GetRangeBase();
|
|
|
|
if (next_base_addr > curr_base_addr) {
|
|
|
|
addr_t size_to_next_symbol = next_base_addr - curr_base_addr;
|
|
|
|
|
2018-05-01 00:49:04 +08:00
|
|
|
// Take the difference between this symbol and the next one as
|
|
|
|
// its size, if it is less than the size of the section.
|
2016-09-07 04:57:50 +08:00
|
|
|
if (sym_size == 0 || size_to_next_symbol < sym_size) {
|
|
|
|
sym_size = size_to_next_symbol;
|
|
|
|
}
|
|
|
|
break;
|
2013-07-10 09:23:25 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (sym_size > 0) {
|
|
|
|
entry->SetByteSize(sym_size);
|
|
|
|
Symbol &symbol = m_symbols[entry->data];
|
|
|
|
symbol.SetByteSize(sym_size);
|
|
|
|
symbol.SetSizeIsSynthesized(true);
|
|
|
|
}
|
2010-10-08 12:20:14 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-02-18 19:12:18 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// Sort again in case the range size changes the ordering
|
|
|
|
m_file_addr_to_index.Sort();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::CalculateSymbolSizes() {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2019-01-04 18:11:25 +08:00
|
|
|
// Size computation happens inside InitAddressIndexes.
|
|
|
|
InitAddressIndexes();
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Symbol *Symtab::FindSymbolAtFileAddress(addr_t file_addr) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
if (!m_file_addr_to_index_computed)
|
|
|
|
InitAddressIndexes();
|
|
|
|
|
|
|
|
const FileRangeToIndexMap::Entry *entry =
|
|
|
|
m_file_addr_to_index.FindEntryStartsAt(file_addr);
|
|
|
|
if (entry) {
|
|
|
|
Symbol *symbol = SymbolAtIndex(entry->data);
|
|
|
|
if (symbol->GetFileAddress() == file_addr)
|
|
|
|
return symbol;
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
}
|
2010-10-08 12:20:14 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
Symbol *Symtab::FindSymbolContainingFileAddress(addr_t file_addr) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2010-06-09 00:52:24 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_file_addr_to_index_computed)
|
|
|
|
InitAddressIndexes();
|
|
|
|
|
|
|
|
const FileRangeToIndexMap::Entry *entry =
|
|
|
|
m_file_addr_to_index.FindEntryThatContains(file_addr);
|
|
|
|
if (entry) {
|
|
|
|
Symbol *symbol = SymbolAtIndex(entry->data);
|
|
|
|
if (symbol->ContainsFileAddress(file_addr))
|
|
|
|
return symbol;
|
|
|
|
}
|
|
|
|
return nullptr;
|
2010-06-09 00:52:24 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::ForEachSymbolContainingFileAddress(
|
|
|
|
addr_t file_addr, std::function<bool(Symbol *)> const &callback) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
2016-01-23 18:36:06 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_file_addr_to_index_computed)
|
|
|
|
InitAddressIndexes();
|
2016-01-23 18:36:06 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
std::vector<uint32_t> all_addr_indexes;
|
2016-01-23 18:36:06 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
// Get all symbols with file_addr
|
|
|
|
const size_t addr_match_count =
|
|
|
|
m_file_addr_to_index.FindEntryIndexesThatContain(file_addr,
|
|
|
|
all_addr_indexes);
|
2016-01-23 18:36:06 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
for (size_t i = 0; i < addr_match_count; ++i) {
|
|
|
|
Symbol *symbol = SymbolAtIndex(all_addr_indexes[i]);
|
|
|
|
if (symbol->ContainsFileAddress(file_addr)) {
|
|
|
|
if (!callback(symbol))
|
|
|
|
break;
|
2016-01-23 18:36:06 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2016-01-23 18:36:06 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
void Symtab::SymbolIndicesToSymbolContextList(
|
|
|
|
std::vector<uint32_t> &symbol_indexes, SymbolContextList &sc_list) {
|
|
|
|
// No need to protect this call using m_mutex all other method calls are
|
|
|
|
// already thread safe.
|
|
|
|
|
|
|
|
const bool merge_symbol_into_function = true;
|
|
|
|
size_t num_indices = symbol_indexes.size();
|
|
|
|
if (num_indices > 0) {
|
|
|
|
SymbolContext sc;
|
|
|
|
sc.module_sp = m_objfile->GetModule();
|
|
|
|
for (size_t i = 0; i < num_indices; i++) {
|
|
|
|
sc.symbol = SymbolAtIndex(symbol_indexes[i]);
|
|
|
|
if (sc.symbol)
|
|
|
|
sc_list.AppendIfUnique(sc, merge_symbol_into_function);
|
2013-01-08 08:01:36 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-01-08 08:01:36 +08:00
|
|
|
}
|
|
|
|
|
2019-03-07 05:22:25 +08:00
|
|
|
size_t Symtab::FindFunctionSymbols(ConstString name,
|
2016-09-07 04:57:50 +08:00
|
|
|
uint32_t name_type_mask,
|
|
|
|
SymbolContextList &sc_list) {
|
|
|
|
size_t count = 0;
|
|
|
|
std::vector<uint32_t> symbol_indexes;
|
|
|
|
|
|
|
|
// eFunctionNameTypeAuto should be pre-resolved by a call to
|
2016-10-01 04:38:33 +08:00
|
|
|
// Module::LookupInfo::LookupInfo()
|
2016-09-07 04:57:50 +08:00
|
|
|
assert((name_type_mask & eFunctionNameTypeAuto) == 0);
|
|
|
|
|
|
|
|
if (name_type_mask & (eFunctionNameTypeBase | eFunctionNameTypeFull)) {
|
|
|
|
std::vector<uint32_t> temp_symbol_indexes;
|
|
|
|
FindAllSymbolsWithNameAndType(name, eSymbolTypeAny, temp_symbol_indexes);
|
|
|
|
|
|
|
|
unsigned temp_symbol_indexes_size = temp_symbol_indexes.size();
|
|
|
|
if (temp_symbol_indexes_size > 0) {
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(m_mutex);
|
|
|
|
for (unsigned i = 0; i < temp_symbol_indexes_size; i++) {
|
|
|
|
SymbolContext sym_ctx;
|
|
|
|
sym_ctx.symbol = SymbolAtIndex(temp_symbol_indexes[i]);
|
|
|
|
if (sym_ctx.symbol) {
|
|
|
|
switch (sym_ctx.symbol->GetType()) {
|
|
|
|
case eSymbolTypeCode:
|
|
|
|
case eSymbolTypeResolver:
|
|
|
|
case eSymbolTypeReExported:
|
|
|
|
symbol_indexes.push_back(temp_symbol_indexes[i]);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2013-04-03 10:00:15 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-04-03 10:00:15 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-04-03 10:00:15 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (name_type_mask & eFunctionNameTypeBase) {
|
2018-05-01 00:49:04 +08:00
|
|
|
// From mangled names we can't tell what is a basename and what is a method
|
|
|
|
// name, so we just treat them the same
|
2016-09-07 04:57:50 +08:00
|
|
|
if (!m_name_indexes_computed)
|
|
|
|
InitNameIndexes();
|
|
|
|
|
|
|
|
if (!m_basename_to_index.IsEmpty()) {
|
|
|
|
const UniqueCStringMap<uint32_t>::Entry *match;
|
2017-05-02 18:17:30 +08:00
|
|
|
for (match = m_basename_to_index.FindFirstValueForName(name);
|
2016-09-07 04:57:50 +08:00
|
|
|
match != nullptr;
|
|
|
|
match = m_basename_to_index.FindNextValueForName(match)) {
|
|
|
|
symbol_indexes.push_back(match->value);
|
|
|
|
}
|
2013-01-08 08:01:36 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-01-08 08:01:36 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (name_type_mask & eFunctionNameTypeMethod) {
|
|
|
|
if (!m_name_indexes_computed)
|
|
|
|
InitNameIndexes();
|
|
|
|
|
|
|
|
if (!m_method_to_index.IsEmpty()) {
|
|
|
|
const UniqueCStringMap<uint32_t>::Entry *match;
|
2017-05-02 18:17:30 +08:00
|
|
|
for (match = m_method_to_index.FindFirstValueForName(name);
|
2016-09-07 04:57:50 +08:00
|
|
|
match != nullptr;
|
|
|
|
match = m_method_to_index.FindNextValueForName(match)) {
|
|
|
|
symbol_indexes.push_back(match->value);
|
|
|
|
}
|
2013-01-08 08:01:36 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
2013-01-08 08:01:36 +08:00
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
if (name_type_mask & eFunctionNameTypeSelector) {
|
|
|
|
if (!m_name_indexes_computed)
|
|
|
|
InitNameIndexes();
|
|
|
|
|
|
|
|
if (!m_selector_to_index.IsEmpty()) {
|
|
|
|
const UniqueCStringMap<uint32_t>::Entry *match;
|
2017-05-02 18:17:30 +08:00
|
|
|
for (match = m_selector_to_index.FindFirstValueForName(name);
|
2016-09-07 04:57:50 +08:00
|
|
|
match != nullptr;
|
|
|
|
match = m_selector_to_index.FindNextValueForName(match)) {
|
|
|
|
symbol_indexes.push_back(match->value);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!symbol_indexes.empty()) {
|
2019-01-09 07:25:06 +08:00
|
|
|
llvm::sort(symbol_indexes.begin(), symbol_indexes.end());
|
2016-09-07 04:57:50 +08:00
|
|
|
symbol_indexes.erase(
|
|
|
|
std::unique(symbol_indexes.begin(), symbol_indexes.end()),
|
|
|
|
symbol_indexes.end());
|
|
|
|
count = symbol_indexes.size();
|
|
|
|
SymbolIndicesToSymbolContextList(symbol_indexes, sc_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
return count;
|
2013-01-08 08:01:36 +08:00
|
|
|
}
|
|
|
|
|
2016-09-07 04:57:50 +08:00
|
|
|
const Symbol *Symtab::GetParent(Symbol *child_symbol) const {
|
|
|
|
uint32_t child_idx = GetIndexForSymbol(child_symbol);
|
|
|
|
if (child_idx != UINT32_MAX && child_idx > 0) {
|
|
|
|
for (uint32_t idx = child_idx - 1; idx != UINT32_MAX; --idx) {
|
|
|
|
const Symbol *symbol = SymbolAtIndex(idx);
|
|
|
|
const uint32_t sibling_idx = symbol->GetSiblingIndex();
|
|
|
|
if (sibling_idx != UINT32_MAX && sibling_idx > child_idx)
|
|
|
|
return symbol;
|
2015-02-26 06:41:34 +08:00
|
|
|
}
|
2016-09-07 04:57:50 +08:00
|
|
|
}
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 19:14:47 +08:00
|
|
|
return nullptr;
|
2015-02-26 06:41:34 +08:00
|
|
|
}
|