[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:23:27 +01:00
|
|
|
//===-- ClangExpressionDeclMap.cpp ----------------------------------------===//
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00: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-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-09-25 20:35:58 +00:00
|
|
|
#include "ClangExpressionDeclMap.h"
|
|
|
|
|
|
|
|
#include "ClangASTSource.h"
|
2022-07-12 09:40:12 +01:00
|
|
|
#include "ClangExpressionUtil.h"
|
|
|
|
#include "ClangExpressionVariable.h"
|
2015-09-25 20:35:58 +00:00
|
|
|
#include "ClangModulesDeclVendor.h"
|
|
|
|
#include "ClangPersistentVariables.h"
|
[lldb] Move clang-based files out of Symbol
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
2020-01-29 11:59:28 -08:00
|
|
|
#include "ClangUtil.h"
|
2015-09-25 20:35:58 +00:00
|
|
|
|
2022-07-12 09:40:12 +01:00
|
|
|
#include "NameSearchContext.h"
|
[lldb] Move clang-based files out of Symbol
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
2020-01-29 11:59:28 -08:00
|
|
|
#include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Core/Address.h"
|
|
|
|
#include "lldb/Core/Module.h"
|
2013-10-21 18:40:51 +00:00
|
|
|
#include "lldb/Core/ModuleSpec.h"
|
2010-12-16 03:17:46 +00:00
|
|
|
#include "lldb/Core/ValueObjectConstResult.h"
|
2011-12-10 03:12:34 +00:00
|
|
|
#include "lldb/Core/ValueObjectVariable.h"
|
2020-10-14 09:50:59 +02:00
|
|
|
#include "lldb/Expression/DiagnosticManager.h"
|
2013-04-11 00:09:05 +00:00
|
|
|
#include "lldb/Expression/Materializer.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Symbol/CompileUnit.h"
|
2015-09-15 23:44:17 +00:00
|
|
|
#include "lldb/Symbol/CompilerDecl.h"
|
2015-08-24 23:46:31 +00:00
|
|
|
#include "lldb/Symbol/CompilerDeclContext.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Symbol/Function.h"
|
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
#include "lldb/Symbol/SymbolContext.h"
|
Better scheme to lookup alternate mangled name when looking up function address.
Summary:
This change is relevant for inferiors compiled with GCC. GCC does not
emit complete debug info for std::basic_string<...>, and consequently, Clang
(the LLDB compiler) does not generate correct mangled names for certain
functions.
This change removes the hard-coded alternate names in
ItaniumABILanguageRuntime.cpp.
Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could
not evaluate std::string methods (ex. std::string::length). After putting in
the hard-coded names, one could evaluate them. However, it did not still
enable one to call methods on, say for example, std::vector<string>.
This change makes that possible.
There is some amount of incompleteness in this change. Consider the
following example:
std::string hello("hello"), world("world");
std::map<std::string, std::string> m;
m[hello] = world;
One can still not evaluate the expression "m[hello]" in LLDB. Will
address this issue in another pass.
Reviewers: jingham, vharron, evgeny777, spyffe, dawn
Subscribers: clayborg, dawn, lldb-commits
Differential Revision: http://reviews.llvm.org/D12809
llvm-svn: 257113
2016-01-07 23:32:34 +00:00
|
|
|
#include "lldb/Symbol/SymbolFile.h"
|
2011-10-12 00:12:34 +00:00
|
|
|
#include "lldb/Symbol/SymbolVendor.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/Symbol/Type.h"
|
|
|
|
#include "lldb/Symbol/TypeList.h"
|
|
|
|
#include "lldb/Symbol/Variable.h"
|
|
|
|
#include "lldb/Symbol/VariableList.h"
|
2010-07-20 23:31:16 +00:00
|
|
|
#include "lldb/Target/ExecutionContext.h"
|
2010-07-16 00:09:46 +00:00
|
|
|
#include "lldb/Target/Process.h"
|
2010-10-05 20:18:48 +00:00
|
|
|
#include "lldb/Target/RegisterContext.h"
|
2013-11-04 09:33:30 +00:00
|
|
|
#include "lldb/Target/StackFrame.h"
|
2010-07-20 23:31:16 +00:00
|
|
|
#include "lldb/Target/Target.h"
|
2010-12-07 01:56:02 +00:00
|
|
|
#include "lldb/Target/Thread.h"
|
2017-02-14 19:06:07 +00:00
|
|
|
#include "lldb/Utility/Endian.h"
|
2022-02-03 13:26:10 +01:00
|
|
|
#include "lldb/Utility/LLDBLog.h"
|
2017-03-03 20:56:28 +00:00
|
|
|
#include "lldb/Utility/Log.h"
|
2018-08-07 11:07:21 +00:00
|
|
|
#include "lldb/Utility/RegisterValue.h"
|
2017-05-12 04:51:55 +00:00
|
|
|
#include "lldb/Utility/Status.h"
|
2022-07-12 09:40:12 +01:00
|
|
|
#include "lldb/lldb-private-types.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
#include "lldb/lldb-private.h"
|
2015-05-01 00:47:29 +00:00
|
|
|
#include "clang/AST/ASTConsumer.h"
|
2012-09-24 22:25:51 +00:00
|
|
|
#include "clang/AST/ASTContext.h"
|
2017-09-28 20:20:25 +00:00
|
|
|
#include "clang/AST/ASTImporter.h"
|
2010-11-01 23:22:47 +00:00
|
|
|
#include "clang/AST/Decl.h"
|
2010-09-23 03:01:22 +00:00
|
|
|
#include "clang/AST/DeclarationName.h"
|
2017-09-28 20:20:25 +00:00
|
|
|
#include "clang/AST/RecursiveASTVisitor.h"
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2015-09-03 23:27:10 +00:00
|
|
|
#include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
|
2019-07-12 20:09:32 +00:00
|
|
|
#include "Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.h"
|
2019-07-15 22:56:12 +00:00
|
|
|
#include "Plugins/LanguageRuntime/ObjC/ObjCLanguageRuntime.h"
|
2015-09-03 23:27:10 +00:00
|
|
|
|
Just like functions can have a basename and a mangled/demangled name, variable
can too. So now the lldb_private::Variable class has support for this.
Variables now have support for having a basename ("i"), and a mangled name
("_ZN12_GLOBAL__N_11iE"), and a demangled name ("(anonymous namespace)::i").
Nowwhen searching for a variable by name, users might enter the fully qualified
name, or just the basename. So new test functions were added to the Variable
and Mangled classes as:
bool NameMatches (const ConstString &name);
bool NameMatches (const RegularExpression ®ex);
I also modified "ClangExpressionDeclMap::FindVariableInScope" to also search
for global variables that are not in the current file scope by first starting
with the current module, then moving on to all modules.
Fixed an issue in the DWARF parser that could cause a varaible to get parsed
more than once. Now, once we have parsed a VariableSP for a DIE, we cache
the result even if a variable wasn't made so we don't do any re-parsing. Some
DW_TAG_variable DIEs don't have locations, or are missing vital info that
stops a debugger from being able to display anything for it, we parse a NULL
variable shared pointer for these DIEs so we don't keep trying to reparse it.
llvm-svn: 119085
2010-11-14 22:13:40 +00:00
|
|
|
using namespace lldb;
|
2010-06-08 16:52:24 +00:00
|
|
|
using namespace lldb_private;
|
|
|
|
using namespace clang;
|
|
|
|
|
2021-10-05 08:29:16 +02:00
|
|
|
static const char *g_lldb_local_vars_namespace_cstr = "$__lldb_local_vars";
|
2016-02-05 19:10:04 +00:00
|
|
|
|
2022-07-12 09:40:12 +01:00
|
|
|
namespace {
|
|
|
|
/// A lambda is represented by Clang as an artifical class whose
|
|
|
|
/// members are the lambda captures. If we capture a 'this' pointer,
|
|
|
|
/// the artifical class will contain a member variable named 'this'.
|
|
|
|
/// The function returns a ValueObject for the captured 'this' if such
|
|
|
|
/// member exists. If no 'this' was captured, return a nullptr.
|
|
|
|
lldb::ValueObjectSP GetCapturedThisValueObject(StackFrame *frame) {
|
|
|
|
assert(frame);
|
|
|
|
|
|
|
|
if (auto thisValSP = frame->FindVariable(ConstString("this")))
|
|
|
|
if (auto thisThisValSP =
|
|
|
|
thisValSP->GetChildMemberWithName(ConstString("this"), true))
|
|
|
|
return thisThisValSP;
|
|
|
|
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
} // namespace
|
|
|
|
|
2015-10-03 09:09:01 +00:00
|
|
|
ClangExpressionDeclMap::ClangExpressionDeclMap(
|
|
|
|
bool keep_result_in_memory,
|
|
|
|
Materializer::PersistentVariableDelegate *result_delegate,
|
2020-02-03 15:55:18 -08:00
|
|
|
const lldb::TargetSP &target,
|
|
|
|
const std::shared_ptr<ClangASTImporter> &importer, ValueObject *ctx_obj)
|
2019-12-17 13:38:07 +01:00
|
|
|
: ClangASTSource(target, importer), m_found_entities(), m_struct_members(),
|
|
|
|
m_keep_result_in_memory(keep_result_in_memory),
|
2019-02-05 11:35:45 +00:00
|
|
|
m_result_delegate(result_delegate), m_ctx_obj(ctx_obj), m_parser_vars(),
|
|
|
|
m_struct_vars() {
|
2010-12-03 01:38:59 +00:00
|
|
|
EnableStructVars();
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ClangExpressionDeclMap::~ClangExpressionDeclMap() {
|
2011-10-12 22:20:02 +00:00
|
|
|
// Note: The model is now that the parser's AST context and all associated
|
|
|
|
// data does not vanish until the expression has been executed. This means
|
2014-07-06 17:54:58 +00:00
|
|
|
// that valuable lookup data (like namespaces) doesn't vanish, but
|
|
|
|
|
2011-10-12 22:20:02 +00:00
|
|
|
DidParse();
|
2010-12-03 01:38:59 +00:00
|
|
|
DisableStructVars();
|
|
|
|
}
|
|
|
|
|
2013-04-11 00:09:05 +00:00
|
|
|
bool ClangExpressionDeclMap::WillParse(ExecutionContext &exe_ctx,
|
|
|
|
Materializer *materializer) {
|
2010-12-03 01:38:59 +00:00
|
|
|
EnableParserVars();
|
2012-02-10 01:22:05 +00:00
|
|
|
m_parser_vars->m_exe_ctx = exe_ctx;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-09-22 04:58:26 +00:00
|
|
|
Target *target = exe_ctx.GetTargetPtr();
|
|
|
|
if (exe_ctx.GetFramePtr())
|
|
|
|
m_parser_vars->m_sym_ctx =
|
|
|
|
exe_ctx.GetFramePtr()->GetSymbolContext(lldb::eSymbolContextEverything);
|
2013-02-21 22:01:43 +00:00
|
|
|
else if (exe_ctx.GetThreadPtr() &&
|
|
|
|
exe_ctx.GetThreadPtr()->GetStackFrameAtIndex(0))
|
2011-09-22 04:58:26 +00:00
|
|
|
m_parser_vars->m_sym_ctx =
|
|
|
|
exe_ctx.GetThreadPtr()->GetStackFrameAtIndex(0)->GetSymbolContext(
|
|
|
|
lldb::eSymbolContextEverything);
|
|
|
|
else if (exe_ctx.GetProcessPtr()) {
|
2013-02-23 04:12:47 +00:00
|
|
|
m_parser_vars->m_sym_ctx.Clear(true);
|
2011-09-22 04:58:26 +00:00
|
|
|
m_parser_vars->m_sym_ctx.target_sp = exe_ctx.GetTargetSP();
|
|
|
|
} else if (target) {
|
2013-02-23 04:12:47 +00:00
|
|
|
m_parser_vars->m_sym_ctx.Clear(true);
|
2011-09-22 04:58:26 +00:00
|
|
|
m_parser_vars->m_sym_ctx.target_sp = exe_ctx.GetTargetSP();
|
2011-09-17 08:33:22 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-09-22 04:58:26 +00:00
|
|
|
if (target) {
|
2015-10-01 16:28:02 +00:00
|
|
|
m_parser_vars->m_persistent_vars = llvm::cast<ClangPersistentVariables>(
|
|
|
|
target->GetPersistentExpressionStateForLanguage(eLanguageTypeC));
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-12-04 10:26:03 +01:00
|
|
|
if (!ScratchTypeSystemClang::GetForTarget(*target))
|
2011-09-22 04:58:26 +00:00
|
|
|
return false;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
m_parser_vars->m_target_info = GetTargetInfo();
|
2013-04-11 00:09:05 +00:00
|
|
|
m_parser_vars->m_materializer = materializer;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-08-01 18:18:33 +00:00
|
|
|
return true;
|
2010-12-03 01:38:59 +00:00
|
|
|
}
|
2010-10-26 00:31:56 +00:00
|
|
|
|
2015-05-01 00:47:29 +00:00
|
|
|
void ClangExpressionDeclMap::InstallCodeGenerator(
|
|
|
|
clang::ASTConsumer *code_gen) {
|
|
|
|
assert(m_parser_vars);
|
|
|
|
m_parser_vars->m_code_gen = code_gen;
|
|
|
|
}
|
|
|
|
|
2020-10-14 09:50:59 +02:00
|
|
|
void ClangExpressionDeclMap::InstallDiagnosticManager(
|
|
|
|
DiagnosticManager &diag_manager) {
|
|
|
|
assert(m_parser_vars);
|
|
|
|
m_parser_vars->m_diagnostics = &diag_manager;
|
|
|
|
}
|
|
|
|
|
2010-12-14 02:59:59 +00:00
|
|
|
void ClangExpressionDeclMap::DidParse() {
|
2020-01-08 14:18:47 -08:00
|
|
|
if (m_parser_vars && m_parser_vars->m_persistent_vars) {
|
2010-12-14 02:59:59 +00:00
|
|
|
for (size_t entity_index = 0, num_entities = m_found_entities.GetSize();
|
2010-12-03 01:38:59 +00:00
|
|
|
entity_index < num_entities; ++entity_index) {
|
2015-09-04 20:49:51 +00:00
|
|
|
ExpressionVariableSP var_sp(
|
|
|
|
m_found_entities.GetVariableAtIndex(entity_index));
|
2015-09-14 21:03:44 +00:00
|
|
|
if (var_sp)
|
|
|
|
llvm::cast<ClangExpressionVariable>(var_sp.get())
|
|
|
|
->DisableParserVars(GetParserID());
|
2010-12-03 01:38:59 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-12-14 02:59:59 +00:00
|
|
|
for (size_t pvar_index = 0,
|
2016-03-19 00:51:43 +00:00
|
|
|
num_pvars = m_parser_vars->m_persistent_vars->GetSize();
|
2015-12-12 19:31:41 +00:00
|
|
|
pvar_index < num_pvars; ++pvar_index) {
|
2015-09-04 20:49:51 +00:00
|
|
|
ExpressionVariableSP pvar_sp(
|
|
|
|
m_parser_vars->m_persistent_vars->GetVariableAtIndex(pvar_index));
|
2015-09-08 22:23:39 +00:00
|
|
|
if (ClangExpressionVariable *clang_var =
|
|
|
|
llvm::dyn_cast<ClangExpressionVariable>(pvar_sp.get()))
|
2010-12-03 01:38:59 +00:00
|
|
|
clang_var->DisableParserVars(GetParserID());
|
2010-10-08 01:58:41 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-09-08 22:23:39 +00:00
|
|
|
DisableParserVars();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
2010-07-13 21:41:46 +00:00
|
|
|
// Interface for IRForTarget
|
|
|
|
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
ClangExpressionDeclMap::TargetInfo ClangExpressionDeclMap::GetTargetInfo() {
|
|
|
|
assert(m_parser_vars.get());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
TargetInfo ret;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-02-10 01:22:05 +00:00
|
|
|
ExecutionContext &exe_ctx = m_parser_vars->m_exe_ctx;
|
|
|
|
|
|
|
|
Process *process = exe_ctx.GetProcessPtr();
|
|
|
|
if (process) {
|
|
|
|
ret.byte_order = process->GetByteOrder();
|
|
|
|
ret.address_byte_size = process->GetAddressByteSize();
|
2014-07-06 17:54:58 +00:00
|
|
|
} else {
|
2012-02-10 01:22:05 +00:00
|
|
|
Target *target = exe_ctx.GetTargetPtr();
|
|
|
|
if (target) {
|
|
|
|
ret.byte_order = target->GetArchitecture().GetByteOrder();
|
|
|
|
ret.address_byte_size = target->GetArchitecture().GetAddressByteSize();
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2012-02-10 01:22:05 +00:00
|
|
|
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeFromUser ClangExpressionDeclMap::DeportType(TypeSystemClang &target,
|
|
|
|
TypeSystemClang &source,
|
2017-09-28 20:20:25 +00:00
|
|
|
TypeFromParser parser_type) {
|
2020-12-10 17:42:46 +01:00
|
|
|
assert(&target == GetScratchContext(*m_target));
|
2019-07-23 21:14:23 +00:00
|
|
|
assert((TypeSystem *)&source == parser_type.GetTypeSystem());
|
2019-12-21 22:40:52 +01:00
|
|
|
assert(&source.getASTContext() == m_ast_context);
|
2019-07-23 21:14:23 +00:00
|
|
|
|
2020-01-31 13:00:32 +01:00
|
|
|
return TypeFromUser(m_ast_importer_sp->DeportType(target, parser_type));
|
2017-09-28 20:20:25 +00:00
|
|
|
}
|
|
|
|
|
2014-07-06 17:54:58 +00:00
|
|
|
bool ClangExpressionDeclMap::AddPersistentVariable(const NamedDecl *decl,
|
2019-03-06 21:22:25 +00:00
|
|
|
ConstString name,
|
2011-01-13 08:53:35 +00:00
|
|
|
TypeFromParser parser_type,
|
|
|
|
bool is_result,
|
|
|
|
bool is_lvalue) {
|
2010-12-03 01:38:59 +00:00
|
|
|
assert(m_parser_vars.get());
|
2015-09-08 18:15:05 +00:00
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *ast =
|
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(parser_type.GetTypeSystem());
|
This commit changes the way LLDB executes user
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
2013-04-18 22:06:33 +00:00
|
|
|
if (ast == nullptr)
|
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-10-14 09:50:59 +02:00
|
|
|
// Check if we already declared a persistent variable with the same name.
|
|
|
|
if (lldb::ExpressionVariableSP conflicting_var =
|
|
|
|
m_parser_vars->m_persistent_vars->GetVariable(name)) {
|
|
|
|
std::string msg = llvm::formatv("redefinition of persistent variable '{0}'",
|
|
|
|
name).str();
|
|
|
|
m_parser_vars->m_diagnostics->AddDiagnostic(
|
|
|
|
msg, DiagnosticSeverity::eDiagnosticSeverityError,
|
|
|
|
DiagnosticOrigin::eDiagnosticOriginLLDB);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
This commit changes the way LLDB executes user
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
2013-04-18 22:06:33 +00:00
|
|
|
if (m_parser_vars->m_materializer && is_result) {
|
2017-05-12 04:51:55 +00:00
|
|
|
Status err;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-08-11 21:38:15 +00:00
|
|
|
ExecutionContext &exe_ctx = m_parser_vars->m_exe_ctx;
|
|
|
|
Target *target = exe_ctx.GetTargetPtr();
|
|
|
|
if (target == nullptr)
|
2015-09-08 18:15:05 +00:00
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-12-10 17:42:46 +01:00
|
|
|
auto *clang_ast_context = GetScratchContext(*target);
|
2019-11-14 13:41:52 -08:00
|
|
|
if (!clang_ast_context)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
TypeFromUser user_type = DeportType(*clang_ast_context, *ast, parser_type);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
uint32_t offset = m_parser_vars->m_materializer->AddResultVariable(
|
|
|
|
user_type, is_lvalue, m_keep_result_in_memory, m_result_delegate, err);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
ClangExpressionVariable *var = new ClangExpressionVariable(
|
|
|
|
exe_ctx.GetBestExecutionContextScope(), name, user_type,
|
|
|
|
m_parser_vars->m_target_info.byte_order,
|
|
|
|
m_parser_vars->m_target_info.address_byte_size);
|
This commit changes the way LLDB executes user
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
2013-04-18 22:06:33 +00:00
|
|
|
|
|
|
|
m_found_entities.AddNewlyConstructedVariable(var);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
var->EnableParserVars(GetParserID());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
var->GetParserVars(GetParserID());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-01-15 23:29:36 +00:00
|
|
|
parser_vars->m_named_decl = decl;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
This commit changes the way LLDB executes user
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
2013-04-18 22:06:33 +00:00
|
|
|
var->EnableJITVars(GetParserID());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-03-27 23:08:40 +00:00
|
|
|
ClangExpressionVariable::JITVars *jit_vars = var->GetJITVars(GetParserID());
|
2011-09-22 04:58:26 +00:00
|
|
|
|
2015-08-11 21:38:15 +00:00
|
|
|
jit_vars->m_offset = offset;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-11-10 22:54:42 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2011-11-18 03:28:09 +00:00
|
|
|
ExecutionContext &exe_ctx = m_parser_vars->m_exe_ctx;
|
|
|
|
Target *target = exe_ctx.GetTargetPtr();
|
[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 11:14:47 +00:00
|
|
|
if (target == nullptr)
|
2011-11-18 03:28:09 +00:00
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-12-10 17:42:46 +01:00
|
|
|
TypeSystemClang *context = GetScratchContext(*target);
|
2019-11-14 13:41:52 -08:00
|
|
|
if (!context)
|
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2017-09-28 20:20:25 +00:00
|
|
|
TypeFromUser user_type = DeportType(*context, *ast, parser_type);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
if (!user_type.GetOpaqueQualType()) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, "Persistent variable's type wasn't copied successfully");
|
2010-08-23 23:09:38 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
if (!m_parser_vars->m_target_info.IsValid())
|
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-01-08 14:18:47 -08:00
|
|
|
if (!m_parser_vars->m_persistent_vars)
|
|
|
|
return false;
|
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
ClangExpressionVariable *var = llvm::cast<ClangExpressionVariable>(
|
|
|
|
m_parser_vars->m_persistent_vars
|
|
|
|
->CreatePersistentVariable(
|
|
|
|
exe_ctx.GetBestExecutionContextScope(), name, user_type,
|
|
|
|
m_parser_vars->m_target_info.byte_order,
|
2015-10-01 23:07:06 +00:00
|
|
|
m_parser_vars->m_target_info.address_byte_size)
|
2015-09-04 20:49:51 +00:00
|
|
|
.get());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2011-01-13 08:53:35 +00:00
|
|
|
if (!var)
|
2015-09-04 20:49:51 +00:00
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
var->m_frozen_sp->SetHasCompleteType();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2011-01-13 08:53:35 +00:00
|
|
|
if (is_result)
|
2015-09-04 20:49:51 +00:00
|
|
|
var->m_flags |= ClangExpressionVariable::EVNeedsFreezeDry;
|
|
|
|
else
|
|
|
|
var->m_flags |=
|
|
|
|
ClangExpressionVariable::EVKeepInTarget; // explicitly-declared
|
|
|
|
// persistent variables should
|
2016-03-19 00:51:43 +00:00
|
|
|
// persist
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-04-11 02:05:11 +00:00
|
|
|
if (is_lvalue) {
|
2015-09-04 20:49:51 +00:00
|
|
|
var->m_flags |= ClangExpressionVariable::EVIsProgramReference;
|
|
|
|
} else {
|
|
|
|
var->m_flags |= ClangExpressionVariable::EVIsLLDBAllocated;
|
|
|
|
var->m_flags |= ClangExpressionVariable::EVNeedsAllocation;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-04-12 18:10:34 +00:00
|
|
|
if (m_keep_result_in_memory) {
|
2015-09-04 20:49:51 +00:00
|
|
|
var->m_flags |= ClangExpressionVariable::EVKeepInTarget;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, "Created persistent variable with flags {0:x}", var->m_flags);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-08-23 23:09:38 +00:00
|
|
|
var->EnableParserVars(GetParserID());
|
2010-08-11 03:57:18 +00:00
|
|
|
|
2014-07-06 17:54:58 +00:00
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
2010-12-03 01:38:59 +00:00
|
|
|
var->GetParserVars(GetParserID());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-11 02:05:11 +00:00
|
|
|
parser_vars->m_named_decl = decl;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-03-27 23:08:40 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2010-12-03 01:38:59 +00:00
|
|
|
bool ClangExpressionDeclMap::AddValueToStruct(const NamedDecl *decl,
|
2019-03-06 21:22:25 +00:00
|
|
|
ConstString name,
|
2010-10-15 22:48:33 +00:00
|
|
|
llvm::Value *value, size_t size,
|
2010-12-03 01:38:59 +00:00
|
|
|
lldb::offset_t alignment) {
|
|
|
|
assert(m_struct_vars.get());
|
|
|
|
assert(m_parser_vars.get());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
bool is_persistent_variable = false;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
m_struct_vars->m_struct_laid_out = false;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
if (ClangExpressionVariable::FindVariableInList(m_struct_members, decl,
|
2010-08-23 23:09:38 +00:00
|
|
|
GetParserID()))
|
|
|
|
return true;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2011-11-18 03:28:09 +00:00
|
|
|
ClangExpressionVariable *var(ClangExpressionVariable::FindVariableInList(
|
2014-04-04 04:06:10 +00:00
|
|
|
m_found_entities, decl, GetParserID()));
|
|
|
|
|
2020-01-08 14:18:47 -08:00
|
|
|
if (!var && m_parser_vars->m_persistent_vars) {
|
2010-08-23 23:09:38 +00:00
|
|
|
var = ClangExpressionVariable::FindVariableInList(
|
|
|
|
*m_parser_vars->m_persistent_vars, decl, GetParserID());
|
|
|
|
is_persistent_variable = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-09-08 22:23:39 +00:00
|
|
|
if (!var)
|
|
|
|
return false;
|
2013-01-15 23:29:36 +00:00
|
|
|
|
2021-02-12 09:52:18 -08:00
|
|
|
LLDB_LOG(log, "Adding value for (NamedDecl*){0} [{1} - {2}] to the structure",
|
2020-02-25 11:49:36 +01:00
|
|
|
decl, name, var->GetName());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-09-08 22:23:39 +00:00
|
|
|
// We know entity->m_parser_vars is valid because we used a parser variable
|
This commit changes the way LLDB executes user
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
2013-04-18 22:06:33 +00:00
|
|
|
// to find it
|
2014-04-04 04:06:10 +00:00
|
|
|
|
This commit changes the way LLDB executes user
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
2013-04-18 22:06:33 +00:00
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
llvm::cast<ClangExpressionVariable>(var)->GetParserVars(GetParserID());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-09-08 22:23:39 +00:00
|
|
|
parser_vars->m_llvm_value = value;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-09-08 22:23:39 +00:00
|
|
|
if (ClangExpressionVariable::JITVars *jit_vars =
|
|
|
|
llvm::cast<ClangExpressionVariable>(var)->GetJITVars(GetParserID())) {
|
|
|
|
// We already laid this out; do not touch
|
2013-01-15 23:29:36 +00:00
|
|
|
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, "Already placed at {0:x}", jit_vars->m_offset);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
llvm::cast<ClangExpressionVariable>(var)->EnableJITVars(GetParserID());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-11 02:05:11 +00:00
|
|
|
ClangExpressionVariable::JITVars *jit_vars =
|
|
|
|
llvm::cast<ClangExpressionVariable>(var)->GetJITVars(GetParserID());
|
2013-04-11 21:16:36 +00:00
|
|
|
|
2013-04-11 02:05:11 +00:00
|
|
|
jit_vars->m_alignment = alignment;
|
2013-01-15 23:29:36 +00:00
|
|
|
jit_vars->m_size = size;
|
2013-04-11 02:05:11 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
m_struct_members.AddVariable(var->shared_from_this());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-11 21:16:36 +00:00
|
|
|
if (m_parser_vars->m_materializer) {
|
|
|
|
uint32_t offset = 0;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2017-05-12 04:51:55 +00:00
|
|
|
Status err;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-11 21:16:36 +00:00
|
|
|
if (is_persistent_variable) {
|
|
|
|
ExpressionVariableSP var_sp(var->shared_from_this());
|
|
|
|
offset = m_parser_vars->m_materializer->AddPersistentVariable(
|
|
|
|
var_sp, nullptr, err);
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2013-04-11 21:16:36 +00:00
|
|
|
if (const lldb_private::Symbol *sym = parser_vars->m_lldb_sym)
|
|
|
|
offset = m_parser_vars->m_materializer->AddSymbol(*sym, err);
|
|
|
|
else if (const RegisterInfo *reg_info = var->GetRegisterInfo())
|
|
|
|
offset = m_parser_vars->m_materializer->AddRegister(*reg_info, err);
|
2013-04-11 02:05:11 +00:00
|
|
|
else if (parser_vars->m_lldb_var)
|
2013-04-11 21:16:36 +00:00
|
|
|
offset = m_parser_vars->m_materializer->AddVariable(
|
|
|
|
parser_vars->m_lldb_var, err);
|
2022-07-12 09:40:12 +01:00
|
|
|
else if (parser_vars->m_lldb_valobj_provider) {
|
|
|
|
offset = m_parser_vars->m_materializer->AddValueObject(
|
|
|
|
name, parser_vars->m_lldb_valobj_provider, err);
|
|
|
|
}
|
2013-04-11 02:05:11 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2013-04-11 21:16:36 +00:00
|
|
|
if (!err.Success())
|
2010-07-13 21:41:46 +00:00
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, "Placed at {0:x}", offset);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-04-16 23:25:35 +00:00
|
|
|
jit_vars->m_offset =
|
|
|
|
offset; // TODO DoStructLayout() should not change this.
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-07-13 21:41:46 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-07-06 17:54:58 +00:00
|
|
|
bool ClangExpressionDeclMap::DoStructLayout() {
|
2010-12-03 01:38:59 +00:00
|
|
|
assert(m_struct_vars.get());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-12-03 01:38:59 +00:00
|
|
|
if (m_struct_vars->m_struct_laid_out)
|
2010-07-13 21:41:46 +00:00
|
|
|
return true;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-12-03 01:38:59 +00:00
|
|
|
if (!m_parser_vars->m_materializer)
|
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-04-16 23:25:35 +00:00
|
|
|
m_struct_vars->m_struct_alignment =
|
|
|
|
m_parser_vars->m_materializer->GetStructAlignment();
|
|
|
|
m_struct_vars->m_struct_size =
|
|
|
|
m_parser_vars->m_materializer->GetStructByteSize();
|
2010-12-03 01:38:59 +00:00
|
|
|
m_struct_vars->m_struct_laid_out = true;
|
2010-07-13 21:41:46 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-07-06 17:54:58 +00:00
|
|
|
bool ClangExpressionDeclMap::GetStructInfo(uint32_t &num_elements, size_t &size,
|
2014-07-02 17:24:07 +00:00
|
|
|
lldb::offset_t &alignment) {
|
2010-12-03 01:38:59 +00:00
|
|
|
assert(m_struct_vars.get());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-12-14 02:59:59 +00:00
|
|
|
if (!m_struct_vars->m_struct_laid_out)
|
2010-07-13 21:41:46 +00:00
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
num_elements = m_struct_members.GetSize();
|
|
|
|
size = m_struct_vars->m_struct_size;
|
|
|
|
alignment = m_struct_vars->m_struct_alignment;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-01-15 23:29:36 +00:00
|
|
|
return true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-04-12 16:58:26 +00:00
|
|
|
bool ClangExpressionDeclMap::GetStructElement(const NamedDecl *&decl,
|
|
|
|
llvm::Value *&value,
|
2014-07-02 17:24:07 +00:00
|
|
|
lldb::offset_t &offset,
|
2010-10-15 22:48:33 +00:00
|
|
|
ConstString &name,
|
2012-04-12 16:58:26 +00:00
|
|
|
uint32_t index) {
|
|
|
|
assert(m_struct_vars.get());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-01-15 23:29:36 +00:00
|
|
|
if (!m_struct_vars->m_struct_laid_out)
|
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-07-13 21:41:46 +00:00
|
|
|
if (index >= m_struct_members.GetSize())
|
|
|
|
return false;
|
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
ExpressionVariableSP member_sp(m_struct_members.GetVariableAtIndex(index));
|
2010-08-23 23:09:38 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
if (!member_sp)
|
2010-08-23 23:09:38 +00:00
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-08-23 23:09:38 +00:00
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
2015-09-08 22:23:39 +00:00
|
|
|
llvm::cast<ClangExpressionVariable>(member_sp.get())
|
2010-08-23 23:09:38 +00:00
|
|
|
->GetParserVars(GetParserID());
|
|
|
|
ClangExpressionVariable::JITVars *jit_vars =
|
|
|
|
llvm::cast<ClangExpressionVariable>(member_sp.get())
|
2015-09-08 22:23:39 +00:00
|
|
|
->GetJITVars(GetParserID());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
if (!parser_vars || !jit_vars || !member_sp->GetValueObject())
|
|
|
|
return false;
|
2013-01-15 23:29:36 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
decl = parser_vars->m_named_decl;
|
|
|
|
value = parser_vars->m_llvm_value;
|
2013-01-15 23:29:36 +00:00
|
|
|
offset = jit_vars->m_offset;
|
2013-07-11 22:46:58 +00:00
|
|
|
name = member_sp->GetName();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-08-23 23:09:38 +00:00
|
|
|
return true;
|
2010-07-27 02:07:53 +00:00
|
|
|
}
|
|
|
|
|
2013-10-21 18:40:51 +00:00
|
|
|
bool ClangExpressionDeclMap::GetFunctionInfo(const NamedDecl *decl,
|
|
|
|
uint64_t &ptr) {
|
|
|
|
ClangExpressionVariable *entity(ClangExpressionVariable::FindVariableInList(
|
2011-06-23 04:25:29 +00:00
|
|
|
m_found_entities, decl, GetParserID()));
|
|
|
|
|
2011-12-01 02:04:16 +00:00
|
|
|
if (!entity)
|
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// We know m_parser_vars is valid since we searched for the variable by its
|
|
|
|
// NamedDecl
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
entity->GetParserVars(GetParserID());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
ptr = parser_vars->m_lldb_value.GetScalar().ULongLong();
|
2013-02-27 20:13:38 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
return true;
|
2013-10-21 18:40:51 +00:00
|
|
|
}
|
2015-06-25 21:46:34 +00:00
|
|
|
|
|
|
|
addr_t ClangExpressionDeclMap::GetSymbolAddress(Target &target,
|
2013-10-21 18:40:51 +00:00
|
|
|
Process *process,
|
2019-03-06 21:22:25 +00:00
|
|
|
ConstString name,
|
2015-06-25 21:46:34 +00:00
|
|
|
lldb::SymbolType symbol_type,
|
|
|
|
lldb_private::Module *module) {
|
|
|
|
SymbolContextList sc_list;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-10-21 18:40:51 +00:00
|
|
|
if (module)
|
|
|
|
module->FindSymbolsWithNameAndType(name, symbol_type, sc_list);
|
2015-06-25 21:46:34 +00:00
|
|
|
else
|
|
|
|
target.GetImages().FindSymbolsWithNameAndType(name, symbol_type, sc_list);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
const uint32_t num_matches = sc_list.GetSize();
|
|
|
|
addr_t symbol_load_addr = LLDB_INVALID_ADDRESS;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-12-12 19:31:41 +00:00
|
|
|
for (uint32_t i = 0;
|
2011-12-01 02:04:16 +00:00
|
|
|
i < num_matches &&
|
2015-06-25 21:46:34 +00:00
|
|
|
(symbol_load_addr == 0 || symbol_load_addr == LLDB_INVALID_ADDRESS);
|
2016-09-06 20:57:50 +00:00
|
|
|
i++) {
|
2015-06-25 21:46:34 +00:00
|
|
|
SymbolContext sym_ctx;
|
|
|
|
sc_list.GetContextAtIndex(i, sym_ctx);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
const Address sym_address = sym_ctx.symbol->GetAddress();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
if (!sym_address.IsValid())
|
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
switch (sym_ctx.symbol->GetType()) {
|
|
|
|
case eSymbolTypeCode:
|
|
|
|
case eSymbolTypeTrampoline:
|
|
|
|
symbol_load_addr = sym_address.GetCallableLoadAddress(&target);
|
2016-09-06 20:57:50 +00:00
|
|
|
break;
|
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
case eSymbolTypeResolver:
|
|
|
|
symbol_load_addr = sym_address.GetCallableLoadAddress(&target, true);
|
|
|
|
break;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
case eSymbolTypeReExported: {
|
|
|
|
ConstString reexport_name = sym_ctx.symbol->GetReExportedSymbolName();
|
|
|
|
if (reexport_name) {
|
|
|
|
ModuleSP reexport_module_sp;
|
|
|
|
ModuleSpec reexport_module_spec;
|
2013-10-21 18:40:51 +00:00
|
|
|
reexport_module_spec.GetPlatformFileSpec() =
|
2015-06-25 21:46:34 +00:00
|
|
|
sym_ctx.symbol->GetReExportedSymbolSharedLibrary();
|
|
|
|
if (reexport_module_spec.GetPlatformFileSpec()) {
|
|
|
|
reexport_module_sp =
|
|
|
|
target.GetImages().FindFirstModule(reexport_module_spec);
|
|
|
|
if (!reexport_module_sp) {
|
2022-07-25 23:29:30 -07:00
|
|
|
reexport_module_spec.GetPlatformFileSpec().ClearDirectory();
|
2015-06-25 21:46:34 +00:00
|
|
|
reexport_module_sp =
|
|
|
|
target.GetImages().FindFirstModule(reexport_module_spec);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-06-23 04:25:29 +00:00
|
|
|
}
|
2015-06-25 21:46:34 +00:00
|
|
|
symbol_load_addr = GetSymbolAddress(
|
|
|
|
target, process, sym_ctx.symbol->GetReExportedSymbolName(),
|
|
|
|
symbol_type, reexport_module_sp.get());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
} break;
|
|
|
|
|
2012-11-27 01:52:16 +00:00
|
|
|
case eSymbolTypeData:
|
|
|
|
case eSymbolTypeRuntime:
|
2015-06-25 21:46:34 +00:00
|
|
|
case eSymbolTypeVariable:
|
|
|
|
case eSymbolTypeLocal:
|
2012-11-27 01:52:16 +00:00
|
|
|
case eSymbolTypeParam:
|
|
|
|
case eSymbolTypeInvalid:
|
|
|
|
case eSymbolTypeAbsolute:
|
|
|
|
case eSymbolTypeException:
|
|
|
|
case eSymbolTypeSourceFile:
|
|
|
|
case eSymbolTypeHeaderFile:
|
|
|
|
case eSymbolTypeObjectFile:
|
|
|
|
case eSymbolTypeCommonBlock:
|
2015-06-25 21:46:34 +00:00
|
|
|
case eSymbolTypeBlock:
|
|
|
|
case eSymbolTypeVariableType:
|
2012-11-27 01:52:16 +00:00
|
|
|
case eSymbolTypeLineEntry:
|
2015-06-25 21:46:34 +00:00
|
|
|
case eSymbolTypeLineHeader:
|
|
|
|
case eSymbolTypeScopeBegin:
|
|
|
|
case eSymbolTypeScopeEnd:
|
|
|
|
case eSymbolTypeAdditional:
|
|
|
|
case eSymbolTypeCompiler:
|
|
|
|
case eSymbolTypeInstrumentation:
|
|
|
|
case eSymbolTypeUndefined:
|
|
|
|
case eSymbolTypeObjCClass:
|
|
|
|
case eSymbolTypeObjCMetaClass:
|
|
|
|
case eSymbolTypeObjCIVar:
|
|
|
|
symbol_load_addr = sym_address.GetLoadAddress(&target);
|
2016-09-06 20:57:50 +00:00
|
|
|
break;
|
2011-06-23 04:25:29 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-11-15 02:02:04 +00:00
|
|
|
if (symbol_load_addr == LLDB_INVALID_ADDRESS && process) {
|
2019-06-10 20:53:23 +00:00
|
|
|
ObjCLanguageRuntime *runtime = ObjCLanguageRuntime::Get(*process);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-11-15 02:02:04 +00:00
|
|
|
if (runtime) {
|
|
|
|
symbol_load_addr = runtime->LookupRuntimeSymbol(name);
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2011-06-23 04:25:29 +00:00
|
|
|
return symbol_load_addr;
|
2011-01-17 23:42:46 +00:00
|
|
|
}
|
|
|
|
|
2019-03-06 21:22:25 +00:00
|
|
|
addr_t ClangExpressionDeclMap::GetSymbolAddress(ConstString name,
|
2011-12-01 02:04:16 +00:00
|
|
|
lldb::SymbolType symbol_type) {
|
2011-05-08 02:21:26 +00:00
|
|
|
assert(m_parser_vars.get());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-02-10 01:22:05 +00:00
|
|
|
if (!m_parser_vars->m_exe_ctx.GetTargetPtr())
|
2011-05-08 02:21:26 +00:00
|
|
|
return false;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-11-15 02:02:04 +00:00
|
|
|
return GetSymbolAddress(m_parser_vars->m_exe_ctx.GetTargetRef(),
|
|
|
|
m_parser_vars->m_exe_ctx.GetProcessPtr(), name,
|
|
|
|
symbol_type);
|
2011-05-08 02:21:26 +00:00
|
|
|
}
|
|
|
|
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
lldb::VariableSP ClangExpressionDeclMap::FindGlobalVariable(
|
2019-03-06 21:22:25 +00:00
|
|
|
Target &target, ModuleSP &module, ConstString name,
|
2020-02-19 14:14:56 +01:00
|
|
|
const CompilerDeclContext &namespace_decl) {
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
VariableList vars;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-10-12 16:59:31 +00:00
|
|
|
if (module && namespace_decl)
|
2020-02-19 14:14:56 +01:00
|
|
|
module->FindGlobalVariables(name, namespace_decl, -1, vars);
|
2011-10-12 16:59:31 +00:00
|
|
|
else
|
2018-05-31 09:46:26 +00:00
|
|
|
target.GetImages().FindGlobalVariables(name, -1, vars);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-12-23 12:18:49 +01:00
|
|
|
if (vars.GetSize() == 0)
|
|
|
|
return VariableSP();
|
|
|
|
return vars.GetVariableAtIndex(0);
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
}
|
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *ClangExpressionDeclMap::GetTypeSystemClang() {
|
2016-02-05 19:10:04 +00:00
|
|
|
StackFrame *frame = m_parser_vars->m_exe_ctx.GetFramePtr();
|
|
|
|
if (frame == nullptr)
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
SymbolContext sym_ctx = frame->GetSymbolContext(lldb::eSymbolContextFunction |
|
|
|
|
lldb::eSymbolContextBlock);
|
|
|
|
if (sym_ctx.block == nullptr)
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
CompilerDeclContext frame_decl_context = sym_ctx.block->GetDeclContext();
|
|
|
|
if (!frame_decl_context)
|
|
|
|
return nullptr;
|
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
return llvm::dyn_cast_or_null<TypeSystemClang>(
|
2016-02-05 19:10:04 +00:00
|
|
|
frame_decl_context.GetTypeSystem());
|
|
|
|
}
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// Interface for ClangASTSource
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
|
2011-10-28 23:38:38 +00:00
|
|
|
void ClangExpressionDeclMap::FindExternalVisibleDecls(
|
|
|
|
NameSearchContext &context) {
|
|
|
|
assert(m_ast_context);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2011-10-28 23:38:38 +00:00
|
|
|
const ConstString name(context.m_decl_name.getAsString().c_str());
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2016-09-06 20:57:50 +00:00
|
|
|
if (log) {
|
2011-10-12 00:12:34 +00:00
|
|
|
if (!context.m_decl_context)
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log,
|
|
|
|
"ClangExpressionDeclMap::FindExternalVisibleDecls for "
|
|
|
|
"'{0}' in a NULL DeclContext",
|
|
|
|
name);
|
2011-10-12 00:12:34 +00:00
|
|
|
else if (const NamedDecl *context_named_decl =
|
|
|
|
dyn_cast<NamedDecl>(context.m_decl_context))
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log,
|
|
|
|
"ClangExpressionDeclMap::FindExternalVisibleDecls for "
|
|
|
|
"'{0}' in '{1}'",
|
|
|
|
name, context_named_decl->getNameAsString());
|
2016-09-06 20:57:50 +00:00
|
|
|
else
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log,
|
|
|
|
"ClangExpressionDeclMap::FindExternalVisibleDecls for "
|
|
|
|
"'{0}' in a '{1}'",
|
|
|
|
name, context.m_decl_context->getDeclKindName());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2011-10-12 00:12:34 +00:00
|
|
|
if (const NamespaceDecl *namespace_context =
|
|
|
|
dyn_cast<NamespaceDecl>(context.m_decl_context)) {
|
2016-02-05 19:10:04 +00:00
|
|
|
if (namespace_context->getName().str() ==
|
|
|
|
std::string(g_lldb_local_vars_namespace_cstr)) {
|
2019-12-23 10:55:21 +01:00
|
|
|
CompilerDeclContext compiler_decl_ctx =
|
|
|
|
m_clang_ast_context->CreateDeclContext(
|
|
|
|
const_cast<clang::DeclContext *>(context.m_decl_context));
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
FindExternalVisibleDecls(context, lldb::ModuleSP(), compiler_decl_ctx);
|
2010-11-19 20:20:02 +00:00
|
|
|
return;
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2011-10-14 20:34:21 +00:00
|
|
|
ClangASTImporter::NamespaceMapSP namespace_map =
|
2020-01-31 13:00:32 +01:00
|
|
|
m_ast_importer_sp->GetNamespaceMap(namespace_context);
|
2017-09-28 20:20:25 +00:00
|
|
|
|
|
|
|
if (!namespace_map)
|
|
|
|
return;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOGV(log, " CEDM::FEVD Inspecting (NamespaceMap*){0:x} ({1} entries)",
|
|
|
|
namespace_map.get(), namespace_map->size());
|
2019-07-23 21:14:23 +00:00
|
|
|
|
2020-05-20 15:02:16 +02:00
|
|
|
for (ClangASTImporter::NamespaceMapItem &n : *namespace_map) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Searching namespace {0} in module {1}",
|
2020-05-20 15:02:16 +02:00
|
|
|
n.second.GetName(), n.first->GetFileSpec().GetFilename());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-05-20 15:02:16 +02:00
|
|
|
FindExternalVisibleDecls(context, n.first, n.second);
|
2011-10-12 00:12:34 +00:00
|
|
|
}
|
2011-11-15 02:11:17 +00:00
|
|
|
} else if (isa<TranslationUnitDecl>(context.m_decl_context)) {
|
2015-08-24 23:46:31 +00:00
|
|
|
CompilerDeclContext namespace_decl;
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Searching the root namespace");
|
2016-02-05 19:10:04 +00:00
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
FindExternalVisibleDecls(context, lldb::ModuleSP(), namespace_decl);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2019-07-23 21:14:23 +00:00
|
|
|
|
2017-04-24 23:14:04 +00:00
|
|
|
ClangASTSource::FindExternalVisibleDecls(context);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2019-11-20 13:41:44 +01:00
|
|
|
void ClangExpressionDeclMap::MaybeRegisterFunctionBody(
|
|
|
|
FunctionDecl *copied_function_decl) {
|
|
|
|
if (copied_function_decl->getBody() && m_parser_vars->m_code_gen) {
|
|
|
|
clang::DeclGroupRef decl_group_ref(copied_function_decl);
|
|
|
|
m_parser_vars->m_code_gen->HandleTopLevelDecl(decl_group_ref);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-17 16:12:07 +01:00
|
|
|
clang::NamedDecl *ClangExpressionDeclMap::GetPersistentDecl(ConstString name) {
|
2019-12-17 13:38:07 +01:00
|
|
|
if (!m_parser_vars)
|
2019-12-17 16:12:07 +01:00
|
|
|
return nullptr;
|
2019-11-20 13:41:44 +01:00
|
|
|
Target *target = m_parser_vars->m_exe_ctx.GetTargetPtr();
|
|
|
|
if (!target)
|
2019-12-17 16:12:07 +01:00
|
|
|
return nullptr;
|
2019-11-20 13:41:44 +01:00
|
|
|
|
2020-12-04 10:26:03 +01:00
|
|
|
ScratchTypeSystemClang::GetForTarget(*target);
|
2019-12-17 16:12:07 +01:00
|
|
|
|
2020-01-08 14:18:47 -08:00
|
|
|
if (!m_parser_vars->m_persistent_vars)
|
|
|
|
return nullptr;
|
2019-12-17 16:12:07 +01:00
|
|
|
return m_parser_vars->m_persistent_vars->GetPersistentDecl(name);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ClangExpressionDeclMap::SearchPersistenDecls(NameSearchContext &context,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
const ConstString name) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2019-11-20 13:41:44 +01:00
|
|
|
|
2019-12-17 16:12:07 +01:00
|
|
|
NamedDecl *persistent_decl = GetPersistentDecl(name);
|
2019-11-20 13:41:44 +01:00
|
|
|
|
|
|
|
if (!persistent_decl)
|
|
|
|
return;
|
|
|
|
|
|
|
|
Decl *parser_persistent_decl = CopyDecl(persistent_decl);
|
|
|
|
|
|
|
|
if (!parser_persistent_decl)
|
|
|
|
return;
|
|
|
|
|
|
|
|
NamedDecl *parser_named_decl = dyn_cast<NamedDecl>(parser_persistent_decl);
|
|
|
|
|
|
|
|
if (!parser_named_decl)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (clang::FunctionDecl *parser_function_decl =
|
|
|
|
llvm::dyn_cast<clang::FunctionDecl>(parser_named_decl)) {
|
|
|
|
MaybeRegisterFunctionBody(parser_function_decl);
|
|
|
|
}
|
|
|
|
|
2021-02-12 09:52:18 -08:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Found persistent decl {0}", name);
|
2019-11-20 13:41:44 +01:00
|
|
|
|
|
|
|
context.AddNamedDecl(parser_named_decl);
|
|
|
|
}
|
2014-04-04 04:06:10 +00:00
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
void ClangExpressionDeclMap::LookUpLldbClass(NameSearchContext &context) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2014-04-04 04:06:10 +00:00
|
|
|
|
2010-11-09 23:46:37 +00:00
|
|
|
StackFrame *frame = m_parser_vars->m_exe_ctx.GetFramePtr();
|
|
|
|
SymbolContext sym_ctx;
|
2015-09-15 23:44:17 +00:00
|
|
|
if (frame != nullptr)
|
|
|
|
sym_ctx = frame->GetSymbolContext(lldb::eSymbolContextFunction |
|
|
|
|
lldb::eSymbolContextBlock);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
if (m_ctx_obj) {
|
|
|
|
Status status;
|
|
|
|
lldb::ValueObjectSP ctx_obj_ptr = m_ctx_obj->AddressOf(status);
|
|
|
|
if (!ctx_obj_ptr || status.Fail())
|
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-06-10 12:22:55 +02:00
|
|
|
AddContextClassType(context, TypeFromUser(m_ctx_obj->GetCompilerType()));
|
2019-11-20 14:35:18 +01:00
|
|
|
return;
|
|
|
|
}
|
2019-02-05 09:14:36 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
// Clang is looking for the type of "this"
|
2019-02-05 09:14:36 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
if (frame == nullptr)
|
|
|
|
return;
|
2019-02-05 09:14:36 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
// Find the block that defines the function represented by "sym_ctx"
|
|
|
|
Block *function_block = sym_ctx.GetFunctionBlock();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
if (!function_block)
|
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
CompilerDeclContext function_decl_ctx = function_block->GetDeclContext();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
if (!function_decl_ctx)
|
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
clang::CXXMethodDecl *method_decl =
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang::DeclContextGetAsCXXMethodDecl(function_decl_ctx);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
if (method_decl) {
|
2022-07-12 09:40:12 +01:00
|
|
|
if (auto capturedThis = GetCapturedThisValueObject(frame)) {
|
|
|
|
// We're inside a lambda and we captured a 'this'.
|
|
|
|
// Import the outer class's AST instead of the
|
|
|
|
// (unnamed) lambda structure AST so unqualified
|
|
|
|
// member lookups are understood by the Clang parser.
|
|
|
|
//
|
|
|
|
// If we're in a lambda which didn't capture 'this',
|
|
|
|
// $__lldb_class will correspond to the lambda closure
|
|
|
|
// AST and references to captures will resolve like
|
|
|
|
// regular member varaiable accesses do.
|
|
|
|
TypeFromUser pointee_type =
|
|
|
|
capturedThis->GetCompilerType().GetPointeeType();
|
|
|
|
|
|
|
|
LLDB_LOG(log,
|
|
|
|
" CEDM::FEVD Adding captured type ({0} for"
|
|
|
|
" $__lldb_class: {1}",
|
|
|
|
capturedThis->GetTypeName(), capturedThis->GetName());
|
|
|
|
|
|
|
|
AddContextClassType(context, pointee_type);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
clang::CXXRecordDecl *class_decl = method_decl->getParent();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
QualType class_qual_type(class_decl->getTypeForDecl(), 0);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-12-25 23:43:52 +01:00
|
|
|
TypeFromUser class_user_type(class_qual_type.getAsOpaquePtr(),
|
|
|
|
function_decl_ctx.GetTypeSystem());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-06-17 09:26:01 -07:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Adding type for $__lldb_class: {0}",
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
class_qual_type.getAsString());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2021-06-11 14:51:17 +02:00
|
|
|
AddContextClassType(context, class_user_type);
|
2019-11-20 14:35:18 +01:00
|
|
|
return;
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
// This branch will get hit if we are executing code in the context of
|
|
|
|
// a function that claims to have an object pointer (through
|
|
|
|
// DW_AT_object_pointer?) but is not formally a method of the class.
|
|
|
|
// In that case, just look up the "this" variable in the current scope
|
|
|
|
// and use its type.
|
|
|
|
// FIXME: This code is formally correct, but clang doesn't currently
|
|
|
|
// emit DW_AT_object_pointer
|
|
|
|
// for C++ so it hasn't actually been tested.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 14:35:18 +01:00
|
|
|
VariableList *vars = frame->GetVariableList(false);
|
|
|
|
|
|
|
|
lldb::VariableSP this_var = vars->FindVariable(ConstString("this"));
|
|
|
|
|
|
|
|
if (this_var && this_var->IsInScope(frame) &&
|
|
|
|
this_var->LocationIsValidForFrame(frame)) {
|
|
|
|
Type *this_type = this_var->GetType();
|
|
|
|
|
|
|
|
if (!this_type)
|
|
|
|
return;
|
|
|
|
|
|
|
|
TypeFromUser pointee_type =
|
|
|
|
this_type->GetForwardCompilerType().GetPointeeType();
|
|
|
|
|
2022-06-17 09:26:01 -07:00
|
|
|
LLDB_LOG(log, " FEVD Adding type for $__lldb_class: {0}",
|
2019-11-25 13:27:51 +01:00
|
|
|
ClangUtil::GetQualType(pointee_type).getAsString());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-06-10 12:22:55 +02:00
|
|
|
AddContextClassType(context, pointee_type);
|
2019-11-20 14:35:18 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
void ClangExpressionDeclMap::LookUpLldbObjCClass(NameSearchContext &context) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2019-11-20 14:35:18 +01:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
StackFrame *frame = m_parser_vars->m_exe_ctx.GetFramePtr();
|
2019-11-20 14:35:18 +01:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
if (m_ctx_obj) {
|
|
|
|
Status status;
|
|
|
|
lldb::ValueObjectSP ctx_obj_ptr = m_ctx_obj->AddressOf(status);
|
|
|
|
if (!ctx_obj_ptr || status.Fail())
|
|
|
|
return;
|
2019-11-20 14:35:18 +01:00
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneType(context, TypeFromUser(m_ctx_obj->GetCompilerType()));
|
2019-11-20 15:58:07 +01:00
|
|
|
return;
|
|
|
|
}
|
2019-11-20 14:35:18 +01:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
// Clang is looking for the type of "*self"
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
if (!frame)
|
|
|
|
return;
|
2019-02-05 09:14:36 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
SymbolContext sym_ctx = frame->GetSymbolContext(lldb::eSymbolContextFunction |
|
|
|
|
lldb::eSymbolContextBlock);
|
2019-02-05 09:14:36 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
// Find the block that defines the function represented by "sym_ctx"
|
|
|
|
Block *function_block = sym_ctx.GetFunctionBlock();
|
2019-02-05 09:14:36 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
if (!function_block)
|
|
|
|
return;
|
2019-02-05 09:14:36 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
CompilerDeclContext function_decl_ctx = function_block->GetDeclContext();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
if (!function_decl_ctx)
|
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
clang::ObjCMethodDecl *method_decl =
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang::DeclContextGetAsObjCMethodDecl(function_decl_ctx);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
if (method_decl) {
|
|
|
|
ObjCInterfaceDecl *self_interface = method_decl->getClassInterface();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
if (!self_interface)
|
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
const clang::Type *interface_type = self_interface->getTypeForDecl();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
if (!interface_type)
|
|
|
|
return; // This is unlikely, but we have seen crashes where this
|
|
|
|
// occurred
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-12-25 23:43:52 +01:00
|
|
|
TypeFromUser class_user_type(QualType(interface_type, 0).getAsOpaquePtr(),
|
|
|
|
function_decl_ctx.GetTypeSystem());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-25 13:27:51 +01:00
|
|
|
LLDB_LOG(log, " FEVD[{0}] Adding type for $__lldb_objc_class: {1}",
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
ClangUtil::ToString(interface_type));
|
2014-07-06 17:54:58 +00:00
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneType(context, class_user_type);
|
2019-11-20 15:58:07 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
// This branch will get hit if we are executing code in the context of
|
|
|
|
// a function that claims to have an object pointer (through
|
|
|
|
// DW_AT_object_pointer?) but is not formally a method of the class.
|
|
|
|
// In that case, just look up the "self" variable in the current scope
|
|
|
|
// and use its type.
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
VariableList *vars = frame->GetVariableList(false);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
lldb::VariableSP self_var = vars->FindVariable(ConstString("self"));
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-23 21:09:41 +01:00
|
|
|
if (!self_var)
|
|
|
|
return;
|
|
|
|
if (!self_var->IsInScope(frame))
|
|
|
|
return;
|
|
|
|
if (!self_var->LocationIsValidForFrame(frame))
|
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-23 21:09:41 +01:00
|
|
|
Type *self_type = self_var->GetType();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-23 21:09:41 +01:00
|
|
|
if (!self_type)
|
|
|
|
return;
|
2012-10-30 23:35:54 +00:00
|
|
|
|
2019-11-23 21:09:41 +01:00
|
|
|
CompilerType self_clang_type = self_type->GetFullCompilerType();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
if (TypeSystemClang::IsObjCClassType(self_clang_type)) {
|
2019-11-23 21:09:41 +01:00
|
|
|
return;
|
|
|
|
}
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
if (!TypeSystemClang::IsObjCObjectPointerType(self_clang_type))
|
2019-11-23 21:09:41 +01:00
|
|
|
return;
|
|
|
|
self_clang_type = self_clang_type.GetPointeeType();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-23 21:09:41 +01:00
|
|
|
if (!self_clang_type)
|
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-25 13:27:51 +01:00
|
|
|
LLDB_LOG(log, " FEVD[{0}] Adding type for $__lldb_objc_class: {1}",
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
ClangUtil::ToString(self_type->GetFullCompilerType()));
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-23 21:09:41 +01:00
|
|
|
TypeFromUser class_user_type(self_clang_type);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneType(context, class_user_type);
|
2019-11-20 15:58:07 +01:00
|
|
|
}
|
2013-07-11 22:46:58 +00:00
|
|
|
|
2019-11-21 10:45:04 +01:00
|
|
|
void ClangExpressionDeclMap::LookupLocalVarNamespace(
|
2019-11-23 21:09:41 +01:00
|
|
|
SymbolContext &sym_ctx, NameSearchContext &name_context) {
|
|
|
|
if (sym_ctx.block == nullptr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
CompilerDeclContext frame_decl_context = sym_ctx.block->GetDeclContext();
|
|
|
|
if (!frame_decl_context)
|
|
|
|
return;
|
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *frame_ast = llvm::dyn_cast_or_null<TypeSystemClang>(
|
2019-11-23 21:09:41 +01:00
|
|
|
frame_decl_context.GetTypeSystem());
|
|
|
|
if (!frame_ast)
|
|
|
|
return;
|
|
|
|
|
2019-11-29 13:02:41 +01:00
|
|
|
clang::NamespaceDecl *namespace_decl =
|
|
|
|
m_clang_ast_context->GetUniqueNamespaceDeclaration(
|
2020-03-04 09:30:12 -08:00
|
|
|
g_lldb_local_vars_namespace_cstr, nullptr, OptionalClangModuleID());
|
2019-11-23 21:09:41 +01:00
|
|
|
if (!namespace_decl)
|
|
|
|
return;
|
|
|
|
|
|
|
|
name_context.AddNamedDecl(namespace_decl);
|
|
|
|
clang::DeclContext *ctxt = clang::Decl::castToDeclContext(namespace_decl);
|
|
|
|
ctxt->setHasExternalVisibleStorage(true);
|
2020-02-25 12:28:48 +01:00
|
|
|
name_context.m_found_local_vars_nsp = true;
|
2019-11-21 10:45:04 +01:00
|
|
|
}
|
|
|
|
|
2019-11-21 11:29:59 +01:00
|
|
|
void ClangExpressionDeclMap::LookupInModulesDeclVendor(
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
NameSearchContext &context, ConstString name) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2019-12-17 13:38:07 +01:00
|
|
|
if (!m_target)
|
|
|
|
return;
|
|
|
|
|
2021-05-19 13:54:14 -07:00
|
|
|
std::shared_ptr<ClangModulesDeclVendor> modules_decl_vendor =
|
|
|
|
GetClangModulesDeclVendor();
|
2019-11-23 20:06:50 +01:00
|
|
|
if (!modules_decl_vendor)
|
|
|
|
return;
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2019-11-23 20:06:50 +01:00
|
|
|
bool append = false;
|
|
|
|
uint32_t max_matches = 1;
|
|
|
|
std::vector<clang::NamedDecl *> decls;
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2019-11-23 20:06:50 +01:00
|
|
|
if (!modules_decl_vendor->FindDecls(name, append, max_matches, decls))
|
|
|
|
return;
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2019-11-23 20:06:50 +01:00
|
|
|
assert(!decls.empty() && "FindDecls returned true but no decls?");
|
|
|
|
clang::NamedDecl *const decl_from_modules = decls[0];
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2019-11-23 20:06:50 +01:00
|
|
|
LLDB_LOG(log,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
" CAS::FEVD Matching decl found for "
|
2022-06-17 09:26:01 -07:00
|
|
|
"\"{0}\" in the modules",
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
name);
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2019-11-23 20:06:50 +01:00
|
|
|
clang::Decl *copied_decl = CopyDecl(decl_from_modules);
|
|
|
|
if (!copied_decl) {
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
LLDB_LOG(log, " CAS::FEVD - Couldn't export a "
|
|
|
|
"declaration from the modules");
|
2019-11-23 20:06:50 +01:00
|
|
|
return;
|
|
|
|
}
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2019-11-23 20:06:50 +01:00
|
|
|
if (auto copied_function = dyn_cast<clang::FunctionDecl>(copied_decl)) {
|
|
|
|
MaybeRegisterFunctionBody(copied_function);
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2019-11-23 20:06:50 +01:00
|
|
|
context.AddNamedDecl(copied_function);
|
2019-11-21 11:29:59 +01:00
|
|
|
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_function_with_type_info = true;
|
|
|
|
context.m_found_function = true;
|
2019-11-23 20:06:50 +01:00
|
|
|
} else if (auto copied_var = dyn_cast<clang::VarDecl>(copied_decl)) {
|
|
|
|
context.AddNamedDecl(copied_var);
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_variable = true;
|
2019-11-21 11:29:59 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-21 12:16:00 +01:00
|
|
|
bool ClangExpressionDeclMap::LookupLocalVariable(
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
NameSearchContext &context, ConstString name, SymbolContext &sym_ctx,
|
|
|
|
const CompilerDeclContext &namespace_decl) {
|
2019-11-23 17:01:25 +01:00
|
|
|
if (sym_ctx.block == nullptr)
|
|
|
|
return false;
|
2019-11-21 12:16:00 +01:00
|
|
|
|
2019-11-23 17:01:25 +01:00
|
|
|
CompilerDeclContext decl_context = sym_ctx.block->GetDeclContext();
|
|
|
|
if (!decl_context)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Make sure that the variables are parsed so that we have the
|
|
|
|
// declarations.
|
2019-11-21 12:16:00 +01:00
|
|
|
StackFrame *frame = m_parser_vars->m_exe_ctx.GetFramePtr();
|
2019-11-23 17:01:25 +01:00
|
|
|
VariableListSP vars = frame->GetInScopeVariableList(true);
|
|
|
|
for (size_t i = 0; i < vars->GetSize(); i++)
|
|
|
|
vars->GetVariableAtIndex(i)->GetDecl();
|
|
|
|
|
|
|
|
// Search for declarations matching the name. Do not include imported
|
|
|
|
// decls in the search if we are looking for decls in the artificial
|
|
|
|
// namespace $__lldb_local_vars.
|
|
|
|
std::vector<CompilerDecl> found_decls =
|
|
|
|
decl_context.FindDeclByName(name, namespace_decl.IsValid());
|
2019-11-21 12:16:00 +01:00
|
|
|
|
2019-11-23 17:01:25 +01:00
|
|
|
VariableSP var;
|
|
|
|
bool variable_found = false;
|
|
|
|
for (CompilerDecl decl : found_decls) {
|
|
|
|
for (size_t vi = 0, ve = vars->GetSize(); vi != ve; ++vi) {
|
|
|
|
VariableSP candidate_var = vars->GetVariableAtIndex(vi);
|
|
|
|
if (candidate_var->GetDecl() == decl) {
|
|
|
|
var = candidate_var;
|
|
|
|
break;
|
2019-11-21 12:16:00 +01:00
|
|
|
}
|
|
|
|
}
|
2019-11-23 17:01:25 +01:00
|
|
|
|
|
|
|
if (var && !variable_found) {
|
|
|
|
variable_found = true;
|
|
|
|
ValueObjectSP valobj = ValueObjectVariable::Create(frame, var);
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneVariable(context, var, valobj);
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_variable = true;
|
2019-11-23 17:01:25 +01:00
|
|
|
}
|
2019-11-21 12:16:00 +01:00
|
|
|
}
|
2022-07-12 09:40:12 +01:00
|
|
|
|
|
|
|
// We're in a local_var_lookup but haven't found any local variables
|
|
|
|
// so far. When performing a variable lookup from within the context of
|
|
|
|
// a lambda, we count the lambda captures as local variables. Thus,
|
|
|
|
// see if we captured any variables with the requested 'name'.
|
|
|
|
if (!variable_found) {
|
|
|
|
auto find_capture = [](ConstString varname,
|
|
|
|
StackFrame *frame) -> ValueObjectSP {
|
|
|
|
if (auto lambda = ClangExpressionUtil::GetLambdaValueObject(frame)) {
|
|
|
|
if (auto capture = lambda->GetChildMemberWithName(varname, true)) {
|
|
|
|
return capture;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nullptr;
|
|
|
|
};
|
|
|
|
|
|
|
|
if (auto capture = find_capture(name, frame)) {
|
|
|
|
variable_found = true;
|
|
|
|
context.m_found_variable = true;
|
|
|
|
AddOneVariable(context, std::move(capture), std::move(find_capture));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-23 17:01:25 +01:00
|
|
|
return variable_found;
|
2019-11-21 12:16:00 +01:00
|
|
|
}
|
|
|
|
|
2019-11-29 15:05:42 +01:00
|
|
|
/// Structure to hold the info needed when comparing function
|
|
|
|
/// declarations.
|
|
|
|
namespace {
|
|
|
|
struct FuncDeclInfo {
|
|
|
|
ConstString m_name;
|
|
|
|
CompilerType m_copied_type;
|
|
|
|
uint32_t m_decl_lvl;
|
|
|
|
SymbolContext m_sym_ctx;
|
|
|
|
};
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
SymbolContextList ClangExpressionDeclMap::SearchFunctionsInSymbolContexts(
|
|
|
|
const SymbolContextList &sc_list,
|
|
|
|
const CompilerDeclContext &frame_decl_context) {
|
|
|
|
// First, symplify things by looping through the symbol contexts to
|
|
|
|
// remove unwanted functions and separate out the functions we want to
|
|
|
|
// compare and prune into a separate list. Cache the info needed about
|
|
|
|
// the function declarations in a vector for efficiency.
|
|
|
|
uint32_t num_indices = sc_list.GetSize();
|
|
|
|
SymbolContextList sc_sym_list;
|
|
|
|
std::vector<FuncDeclInfo> decl_infos;
|
|
|
|
decl_infos.reserve(num_indices);
|
|
|
|
clang::DeclContext *frame_decl_ctx =
|
|
|
|
(clang::DeclContext *)frame_decl_context.GetOpaqueDeclContext();
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *ast = llvm::dyn_cast_or_null<TypeSystemClang>(
|
2019-11-29 15:05:42 +01:00
|
|
|
frame_decl_context.GetTypeSystem());
|
|
|
|
|
|
|
|
for (uint32_t index = 0; index < num_indices; ++index) {
|
|
|
|
FuncDeclInfo fdi;
|
|
|
|
SymbolContext sym_ctx;
|
|
|
|
sc_list.GetContextAtIndex(index, sym_ctx);
|
|
|
|
|
|
|
|
// We don't know enough about symbols to compare them, but we should
|
|
|
|
// keep them in the list.
|
|
|
|
Function *function = sym_ctx.function;
|
|
|
|
if (!function) {
|
|
|
|
sc_sym_list.Append(sym_ctx);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// Filter out functions without declaration contexts, as well as
|
|
|
|
// class/instance methods, since they'll be skipped in the code that
|
|
|
|
// follows anyway.
|
|
|
|
CompilerDeclContext func_decl_context = function->GetDeclContext();
|
|
|
|
if (!func_decl_context ||
|
|
|
|
func_decl_context.IsClassMethod(nullptr, nullptr, nullptr))
|
|
|
|
continue;
|
|
|
|
// We can only prune functions for which we can copy the type.
|
|
|
|
CompilerType func_clang_type = function->GetType()->GetFullCompilerType();
|
|
|
|
CompilerType copied_func_type = GuardedCopyType(func_clang_type);
|
|
|
|
if (!copied_func_type) {
|
|
|
|
sc_sym_list.Append(sym_ctx);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
fdi.m_sym_ctx = sym_ctx;
|
|
|
|
fdi.m_name = function->GetName();
|
|
|
|
fdi.m_copied_type = copied_func_type;
|
|
|
|
fdi.m_decl_lvl = LLDB_INVALID_DECL_LEVEL;
|
|
|
|
if (fdi.m_copied_type && func_decl_context) {
|
|
|
|
// Call CountDeclLevels to get the number of parent scopes we have
|
|
|
|
// to look through before we find the function declaration. When
|
|
|
|
// comparing functions of the same type, the one with a lower count
|
|
|
|
// will be closer to us in the lookup scope and shadows the other.
|
|
|
|
clang::DeclContext *func_decl_ctx =
|
|
|
|
(clang::DeclContext *)func_decl_context.GetOpaqueDeclContext();
|
|
|
|
fdi.m_decl_lvl = ast->CountDeclLevels(frame_decl_ctx, func_decl_ctx,
|
|
|
|
&fdi.m_name, &fdi.m_copied_type);
|
|
|
|
}
|
|
|
|
decl_infos.emplace_back(fdi);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Loop through the functions in our cache looking for matching types,
|
|
|
|
// then compare their scope levels to see which is closer.
|
|
|
|
std::multimap<CompilerType, const FuncDeclInfo *> matches;
|
|
|
|
for (const FuncDeclInfo &fdi : decl_infos) {
|
|
|
|
const CompilerType t = fdi.m_copied_type;
|
|
|
|
auto q = matches.find(t);
|
|
|
|
if (q != matches.end()) {
|
|
|
|
if (q->second->m_decl_lvl > fdi.m_decl_lvl)
|
|
|
|
// This function is closer; remove the old set.
|
|
|
|
matches.erase(t);
|
|
|
|
else if (q->second->m_decl_lvl < fdi.m_decl_lvl)
|
|
|
|
// The functions in our set are closer - skip this one.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
matches.insert(std::make_pair(t, &fdi));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Loop through our matches and add their symbol contexts to our list.
|
|
|
|
SymbolContextList sc_func_list;
|
|
|
|
for (const auto &q : matches)
|
|
|
|
sc_func_list.Append(q.second->m_sym_ctx);
|
|
|
|
|
|
|
|
// Rejoin the lists with the functions in front.
|
|
|
|
sc_func_list.Append(sc_sym_list);
|
|
|
|
return sc_func_list;
|
|
|
|
}
|
|
|
|
|
2020-02-19 14:14:56 +01:00
|
|
|
void ClangExpressionDeclMap::LookupFunction(
|
|
|
|
NameSearchContext &context, lldb::ModuleSP module_sp, ConstString name,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
const CompilerDeclContext &namespace_decl) {
|
2019-12-17 13:38:07 +01:00
|
|
|
if (!m_parser_vars)
|
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 15:58:07 +01:00
|
|
|
Target *target = m_parser_vars->m_exe_ctx.GetTargetPtr();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
std::vector<clang::NamedDecl *> decls_from_modules;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
if (target) {
|
2021-05-19 13:54:14 -07:00
|
|
|
if (std::shared_ptr<ClangModulesDeclVendor> decl_vendor =
|
|
|
|
GetClangModulesDeclVendor()) {
|
2019-11-20 16:12:50 +01:00
|
|
|
decl_vendor->FindDecls(name, false, UINT32_MAX, decls_from_modules);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2019-11-20 16:12:50 +01:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-21 13:43:48 +01:00
|
|
|
SymbolContextList sc_list;
|
2019-11-20 16:12:50 +01:00
|
|
|
if (namespace_decl && module_sp) {
|
2021-08-05 09:27:19 -07:00
|
|
|
ModuleFunctionSearchOptions function_options;
|
|
|
|
function_options.include_inlines = false;
|
|
|
|
function_options.include_symbols = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-02-17 19:25:52 +01:00
|
|
|
module_sp->FindFunctions(name, namespace_decl, eFunctionNameTypeBase,
|
2021-08-05 09:27:19 -07:00
|
|
|
function_options, sc_list);
|
2019-11-20 16:12:50 +01:00
|
|
|
} else if (target && !namespace_decl) {
|
2021-08-05 09:27:19 -07:00
|
|
|
ModuleFunctionSearchOptions function_options;
|
|
|
|
function_options.include_inlines = false;
|
|
|
|
function_options.include_symbols = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
// TODO Fix FindFunctions so that it doesn't return
|
|
|
|
// instance methods for eFunctionNameTypeBase.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-01-14 14:33:43 +01:00
|
|
|
target->GetImages().FindFunctions(
|
2021-08-05 09:27:19 -07:00
|
|
|
name, eFunctionNameTypeFull | eFunctionNameTypeBase, function_options,
|
|
|
|
sc_list);
|
2019-11-20 16:12:50 +01:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
// If we found more than one function, see if we can use the frame's decl
|
|
|
|
// context to remove functions that are shadowed by other functions which
|
|
|
|
// match in type but are nearer in scope.
|
|
|
|
//
|
|
|
|
// AddOneFunction will not add a function whose type has already been
|
|
|
|
// added, so if there's another function in the list with a matching type,
|
|
|
|
// check to see if their decl context is a parent of the current frame's or
|
|
|
|
// was imported via a and using statement, and pick the best match
|
|
|
|
// according to lookup rules.
|
|
|
|
if (sc_list.GetSize() > 1) {
|
|
|
|
// Collect some info about our frame's context.
|
|
|
|
StackFrame *frame = m_parser_vars->m_exe_ctx.GetFramePtr();
|
|
|
|
SymbolContext frame_sym_ctx;
|
|
|
|
if (frame != nullptr)
|
|
|
|
frame_sym_ctx = frame->GetSymbolContext(lldb::eSymbolContextFunction |
|
|
|
|
lldb::eSymbolContextBlock);
|
|
|
|
CompilerDeclContext frame_decl_context =
|
|
|
|
frame_sym_ctx.block != nullptr ? frame_sym_ctx.block->GetDeclContext()
|
|
|
|
: CompilerDeclContext();
|
|
|
|
|
|
|
|
// We can't do this without a compiler decl context for our frame.
|
|
|
|
if (frame_decl_context) {
|
2019-11-29 15:05:42 +01:00
|
|
|
sc_list = SearchFunctionsInSymbolContexts(sc_list, frame_decl_context);
|
2017-04-24 23:14:04 +00:00
|
|
|
}
|
2019-11-20 16:12:50 +01:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
if (sc_list.GetSize()) {
|
|
|
|
Symbol *extern_symbol = nullptr;
|
|
|
|
Symbol *non_extern_symbol = nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
for (uint32_t index = 0, num_indices = sc_list.GetSize();
|
|
|
|
index < num_indices; ++index) {
|
|
|
|
SymbolContext sym_ctx;
|
|
|
|
sc_list.GetContextAtIndex(index, sym_ctx);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
if (sym_ctx.function) {
|
|
|
|
CompilerDeclContext decl_ctx = sym_ctx.function->GetDeclContext();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
if (!decl_ctx)
|
|
|
|
continue;
|
2017-04-24 23:14:04 +00:00
|
|
|
|
2019-11-20 16:12:50 +01:00
|
|
|
// Filter out class/instance methods.
|
|
|
|
if (decl_ctx.IsClassMethod(nullptr, nullptr, nullptr))
|
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneFunction(context, sym_ctx.function, nullptr);
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_function_with_type_info = true;
|
|
|
|
context.m_found_function = true;
|
2019-11-20 16:12:50 +01:00
|
|
|
} else if (sym_ctx.symbol) {
|
|
|
|
if (sym_ctx.symbol->GetType() == eSymbolTypeReExported && target) {
|
|
|
|
sym_ctx.symbol = sym_ctx.symbol->ResolveReExportedSymbol(*target);
|
|
|
|
if (sym_ctx.symbol == nullptr)
|
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2019-11-20 16:12:50 +01:00
|
|
|
|
|
|
|
if (sym_ctx.symbol->IsExternal())
|
|
|
|
extern_symbol = sym_ctx.symbol;
|
|
|
|
else
|
|
|
|
non_extern_symbol = sym_ctx.symbol;
|
2017-04-24 23:14:04 +00:00
|
|
|
}
|
2019-11-20 16:12:50 +01:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-02-25 12:28:48 +01:00
|
|
|
if (!context.m_found_function_with_type_info) {
|
2019-11-20 16:12:50 +01:00
|
|
|
for (clang::NamedDecl *decl : decls_from_modules) {
|
|
|
|
if (llvm::isa<clang::FunctionDecl>(decl)) {
|
|
|
|
clang::NamedDecl *copied_decl =
|
|
|
|
llvm::cast_or_null<FunctionDecl>(CopyDecl(decl));
|
|
|
|
if (copied_decl) {
|
|
|
|
context.AddNamedDecl(copied_decl);
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_function_with_type_info = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
}
|
2017-04-24 23:14:04 +00:00
|
|
|
}
|
2019-11-20 16:12:50 +01:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-02-25 12:28:48 +01:00
|
|
|
if (!context.m_found_function_with_type_info) {
|
2019-11-20 16:12:50 +01:00
|
|
|
if (extern_symbol) {
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneFunction(context, nullptr, extern_symbol);
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_function = true;
|
2019-11-20 16:12:50 +01:00
|
|
|
} else if (non_extern_symbol) {
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneFunction(context, nullptr, non_extern_symbol);
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_function = true;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2017-04-24 23:14:04 +00:00
|
|
|
}
|
2019-11-20 16:12:50 +01:00
|
|
|
}
|
2019-11-21 13:58:48 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void ClangExpressionDeclMap::FindExternalVisibleDecls(
|
|
|
|
NameSearchContext &context, lldb::ModuleSP module_sp,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
const CompilerDeclContext &namespace_decl) {
|
2019-11-21 13:58:48 +01:00
|
|
|
assert(m_ast_context);
|
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2019-11-21 13:58:48 +01:00
|
|
|
|
|
|
|
const ConstString name(context.m_decl_name.getAsString().c_str());
|
|
|
|
if (IgnoreName(name, false))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Only look for functions by name out in our symbols if the function doesn't
|
|
|
|
// start with our phony prefix of '$'
|
2019-12-17 13:38:07 +01:00
|
|
|
|
|
|
|
Target *target = nullptr;
|
|
|
|
StackFrame *frame = nullptr;
|
2019-11-21 13:58:48 +01:00
|
|
|
SymbolContext sym_ctx;
|
2019-12-17 13:38:07 +01:00
|
|
|
if (m_parser_vars) {
|
|
|
|
target = m_parser_vars->m_exe_ctx.GetTargetPtr();
|
|
|
|
frame = m_parser_vars->m_exe_ctx.GetFramePtr();
|
|
|
|
}
|
2019-11-21 13:58:48 +01:00
|
|
|
if (frame != nullptr)
|
|
|
|
sym_ctx = frame->GetSymbolContext(lldb::eSymbolContextFunction |
|
|
|
|
lldb::eSymbolContextBlock);
|
|
|
|
|
|
|
|
// Try the persistent decls, which take precedence over all else.
|
|
|
|
if (!namespace_decl)
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
SearchPersistenDecls(context, name);
|
2019-11-21 13:58:48 +01:00
|
|
|
|
2019-11-21 14:40:45 +01:00
|
|
|
if (name.GetStringRef().startswith("$") && !namespace_decl) {
|
|
|
|
if (name == "$__lldb_class") {
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
LookUpLldbClass(context);
|
2019-11-21 13:58:48 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-11-21 14:40:45 +01:00
|
|
|
if (name == "$__lldb_objc_class") {
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
LookUpLldbObjCClass(context);
|
2019-11-21 13:58:48 +01:00
|
|
|
return;
|
|
|
|
}
|
2019-11-21 14:40:45 +01:00
|
|
|
if (name == g_lldb_local_vars_namespace_cstr) {
|
2019-11-21 13:58:48 +01:00
|
|
|
LookupLocalVarNamespace(sym_ctx, context);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// any other $__lldb names should be weeded out now
|
|
|
|
if (name.GetStringRef().startswith("$__lldb"))
|
|
|
|
return;
|
|
|
|
|
2019-12-17 16:12:07 +01:00
|
|
|
// No ParserVars means we can't do register or variable lookup.
|
2020-01-08 14:18:47 -08:00
|
|
|
if (!m_parser_vars || !m_parser_vars->m_persistent_vars)
|
2019-12-17 16:12:07 +01:00
|
|
|
return;
|
|
|
|
|
2019-11-21 13:58:48 +01:00
|
|
|
ExpressionVariableSP pvar_sp(
|
|
|
|
m_parser_vars->m_persistent_vars->GetVariable(name));
|
|
|
|
|
|
|
|
if (pvar_sp) {
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneVariable(context, pvar_sp);
|
2019-11-21 13:58:48 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-11-21 14:40:45 +01:00
|
|
|
assert(name.GetStringRef().startswith("$"));
|
|
|
|
llvm::StringRef reg_name = name.GetStringRef().substr(1);
|
2019-11-21 13:58:48 +01:00
|
|
|
|
|
|
|
if (m_parser_vars->m_exe_ctx.GetRegisterContext()) {
|
|
|
|
const RegisterInfo *reg_info(
|
|
|
|
m_parser_vars->m_exe_ctx.GetRegisterContext()->GetRegisterInfoByName(
|
|
|
|
reg_name));
|
|
|
|
|
|
|
|
if (reg_info) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Found register {0}", reg_info->name);
|
2019-11-21 13:58:48 +01:00
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneRegister(context, reg_info);
|
2019-11-21 13:58:48 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-11-21 14:40:45 +01:00
|
|
|
bool local_var_lookup = !namespace_decl || (namespace_decl.GetName() ==
|
|
|
|
g_lldb_local_vars_namespace_cstr);
|
2019-11-21 13:58:48 +01:00
|
|
|
if (frame && local_var_lookup)
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
if (LookupLocalVariable(context, name, sym_ctx, namespace_decl))
|
2019-11-21 13:58:48 +01:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (target) {
|
|
|
|
ValueObjectSP valobj;
|
|
|
|
VariableSP var;
|
2020-02-19 14:14:56 +01:00
|
|
|
var = FindGlobalVariable(*target, module_sp, name, namespace_decl);
|
2019-11-21 13:58:48 +01:00
|
|
|
|
|
|
|
if (var) {
|
|
|
|
valobj = ValueObjectVariable::Create(target, var);
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneVariable(context, var, valobj);
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_variable = true;
|
2019-11-21 13:58:48 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
LookupFunction(context, module_sp, name, namespace_decl);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-21 11:29:59 +01:00
|
|
|
// Try the modules next.
|
2020-02-25 12:28:48 +01:00
|
|
|
if (!context.m_found_function_with_type_info)
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
LookupInModulesDeclVendor(context, name);
|
2019-11-20 16:12:50 +01:00
|
|
|
|
2020-02-25 12:28:48 +01:00
|
|
|
if (target && !context.m_found_variable && !namespace_decl) {
|
2019-11-20 16:12:50 +01:00
|
|
|
// We couldn't find a non-symbol variable for this. Now we'll hunt for a
|
|
|
|
// generic data symbol, and -- if it is found -- treat it as a variable.
|
|
|
|
Status error;
|
|
|
|
|
|
|
|
const Symbol *data_symbol =
|
|
|
|
m_parser_vars->m_sym_ctx.FindBestGlobalDataSymbol(name, error);
|
|
|
|
|
|
|
|
if (!error.Success()) {
|
|
|
|
const unsigned diag_id =
|
|
|
|
m_ast_context->getDiagnostics().getCustomDiagID(
|
|
|
|
clang::DiagnosticsEngine::Level::Error, "%0");
|
|
|
|
m_ast_context->getDiagnostics().Report(diag_id) << error.AsCString();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (data_symbol) {
|
|
|
|
std::string warning("got name from symbols: ");
|
|
|
|
warning.append(name.AsCString());
|
|
|
|
const unsigned diag_id =
|
|
|
|
m_ast_context->getDiagnostics().getCustomDiagID(
|
|
|
|
clang::DiagnosticsEngine::Level::Warning, "%0");
|
|
|
|
m_ast_context->getDiagnostics().Report(diag_id) << warning.c_str();
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
AddOneGenericVariable(context, *data_symbol);
|
2020-02-25 12:28:48 +01:00
|
|
|
context.m_found_variable = true;
|
2011-10-27 02:06:03 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2011-06-25 00:44:06 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
bool ClangExpressionDeclMap::GetVariableValue(VariableSP &var,
|
|
|
|
lldb_private::Value &var_location,
|
|
|
|
TypeFromUser *user_type,
|
|
|
|
TypeFromParser *parser_type) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions.
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
2015-09-17 22:23:34 +00:00
|
|
|
Type *var_type = var->GetType();
|
|
|
|
|
2014-07-06 17:54:58 +00:00
|
|
|
if (!var_type) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, "Skipped a definition because it has no type");
|
2013-07-11 22:46:58 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions.
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
2015-09-17 22:23:34 +00:00
|
|
|
|
|
|
|
CompilerType var_clang_type = var_type->GetFullCompilerType();
|
2013-07-11 22:46:58 +00:00
|
|
|
|
A few of the issue I have been trying to track down and fix have been due to
the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.
A few months ago I worked with the llvm/clang folks to have the
ExternalASTSource class be able to complete classes if there weren't completed
yet:
class ExternalASTSource {
....
virtual void
CompleteType (clang::TagDecl *Tag);
virtual void
CompleteType (clang::ObjCInterfaceDecl *Class);
};
This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.
This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
ClangASTType, and more) can now be iterating through children of any type,
and if a class/union/struct type (clang::RecordType or ObjC interface)
is found that is incomplete, we can ask the AST to get the definition.
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
all child SymbolFileDWARF classes will share (much like what happens when
we have a complete linked DWARF for an executable).
We will need to modify some of the ClangUserExpression code to take more
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.
llvm-svn: 123613
2011-01-17 03:46:26 +00:00
|
|
|
if (!var_clang_type) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, "Skipped a definition because it has no Clang type");
|
2013-07-11 22:46:58 +00:00
|
|
|
return false;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *clang_ast = llvm::dyn_cast_or_null<TypeSystemClang>(
|
2010-07-17 00:43:37 +00:00
|
|
|
var_type->GetForwardCompilerType().GetTypeSystem());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions.
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
2015-09-17 22:23:34 +00:00
|
|
|
if (!clang_ast) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, "Skipped a definition because it has no Clang AST");
|
2010-06-08 16:52:24 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2022-07-12 10:30:49 -07:00
|
|
|
DWARFExpressionList &var_location_list = var->LocationExpressionList();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2012-02-10 01:22:05 +00:00
|
|
|
Target *target = m_parser_vars->m_exe_ctx.GetTargetPtr();
|
2017-05-12 04:51:55 +00:00
|
|
|
Status err;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-18 21:20:51 +00:00
|
|
|
if (var->GetLocationIsConstantValueData()) {
|
|
|
|
DataExtractor const_value_extractor;
|
2022-07-12 10:30:49 -07:00
|
|
|
if (var_location_list.GetExpressionData(const_value_extractor)) {
|
2013-07-11 22:46:58 +00:00
|
|
|
var_location = Value(const_value_extractor.GetDataStart(),
|
|
|
|
const_value_extractor.GetByteSize());
|
2021-02-11 12:57:04 -08:00
|
|
|
var_location.SetValueType(Value::ValueType::HostAddress);
|
2013-01-18 21:20:51 +00:00
|
|
|
} else {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, "Error evaluating constant variable: {0}", err.AsCString());
|
2013-07-11 22:46:58 +00:00
|
|
|
return false;
|
2013-01-18 21:20:51 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-08-11 22:53:00 +00:00
|
|
|
CompilerType type_to_use = GuardedCopyType(var_clang_type);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
if (!type_to_use) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log,
|
|
|
|
"Couldn't copy a variable's type into the parser's AST context");
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
return false;
|
2010-07-20 23:31:16 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
if (parser_type)
|
|
|
|
*parser_type = TypeFromParser(type_to_use);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2021-02-11 12:57:04 -08:00
|
|
|
if (var_location.GetContextType() == Value::ContextType::Invalid)
|
2015-08-24 23:46:31 +00:00
|
|
|
var_location.SetCompilerType(type_to_use);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2021-02-11 12:57:04 -08:00
|
|
|
if (var_location.GetValueType() == Value::ValueType::FileAddress) {
|
2010-06-08 16:52:24 +00:00
|
|
|
SymbolContext var_sc;
|
|
|
|
var->CalculateSymbolContext(&var_sc);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
if (!var_sc.module_sp)
|
2013-08-07 19:05:15 +00:00
|
|
|
return false;
|
2013-07-10 01:23:25 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
Address so_addr(var_location.GetScalar().ULongLong(),
|
|
|
|
var_sc.module_sp->GetSectionList());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2011-09-22 04:58:26 +00:00
|
|
|
lldb::addr_t load_addr = so_addr.GetLoadAddress(target);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
This patch modifies the expression parser to allow it
to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
2011-09-15 02:13:07 +00:00
|
|
|
if (load_addr != LLDB_INVALID_ADDRESS) {
|
2013-07-11 22:46:58 +00:00
|
|
|
var_location.GetScalar() = load_addr;
|
2021-02-11 12:57:04 -08:00
|
|
|
var_location.SetValueType(Value::ValueType::LoadAddress);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-07-20 23:31:16 +00:00
|
|
|
if (user_type)
|
2013-07-11 22:46:58 +00:00
|
|
|
*user_type = TypeFromUser(var_clang_type);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
return true;
|
2010-07-17 00:43:37 +00:00
|
|
|
}
|
|
|
|
|
2022-07-12 09:40:12 +01:00
|
|
|
ClangExpressionVariable::ParserVars *
|
|
|
|
ClangExpressionDeclMap::AddExpressionVariable(NameSearchContext &context,
|
|
|
|
TypeFromParser const &pt,
|
|
|
|
ValueObjectSP valobj) {
|
2013-07-11 22:46:58 +00:00
|
|
|
clang::QualType parser_opaque_type =
|
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions.
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
2015-09-17 22:23:34 +00:00
|
|
|
QualType::getFromOpaquePtr(pt.GetOpaqueQualType());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2011-10-27 19:41:13 +00:00
|
|
|
if (parser_opaque_type.isNull())
|
2022-07-12 09:40:12 +01:00
|
|
|
return nullptr;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-03-15 01:53:17 +00:00
|
|
|
if (const clang::Type *parser_type = parser_opaque_type.getTypePtr()) {
|
|
|
|
if (const TagType *tag_type = dyn_cast<TagType>(parser_type))
|
|
|
|
CompleteType(tag_type->getDecl());
|
2013-12-20 04:09:05 +00:00
|
|
|
if (const ObjCObjectPointerType *objc_object_ptr_type =
|
|
|
|
dyn_cast<ObjCObjectPointerType>(parser_type))
|
|
|
|
CompleteType(objc_object_ptr_type->getInterfaceDecl());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
bool is_reference = pt.IsReferenceType();
|
2016-09-06 20:57:50 +00: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 11:14:47 +00:00
|
|
|
NamedDecl *var_decl = nullptr;
|
2011-10-27 19:41:13 +00:00
|
|
|
if (is_reference)
|
2013-07-11 22:46:58 +00:00
|
|
|
var_decl = context.AddVarDecl(pt);
|
2016-09-06 20:57:50 +00:00
|
|
|
else
|
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions.
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
2015-09-17 22:23:34 +00:00
|
|
|
var_decl = context.AddVarDecl(pt.GetLValueReferenceType());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-10-15 22:48:33 +00:00
|
|
|
std::string decl_name(context.m_decl_name.getAsString());
|
2010-12-14 02:59:59 +00:00
|
|
|
ConstString entity_name(decl_name.c_str());
|
2015-10-01 23:07:06 +00:00
|
|
|
ClangExpressionVariable *entity(new ClangExpressionVariable(valobj));
|
|
|
|
m_found_entities.AddNewlyConstructedVariable(entity);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-09-04 20:49:51 +00:00
|
|
|
assert(entity);
|
2013-01-15 23:29:36 +00:00
|
|
|
entity->EnableParserVars(GetParserID());
|
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
entity->GetParserVars(GetParserID());
|
2022-07-12 09:40:12 +01:00
|
|
|
|
2013-01-15 23:29:36 +00:00
|
|
|
parser_vars->m_named_decl = var_decl;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-10-27 19:41:13 +00:00
|
|
|
if (is_reference)
|
|
|
|
entity->m_flags |= ClangExpressionVariable::EVTypeIsReference;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-07-12 09:40:12 +01:00
|
|
|
return parser_vars;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ClangExpressionDeclMap::AddOneVariable(
|
|
|
|
NameSearchContext &context, ValueObjectSP valobj,
|
|
|
|
ValueObjectProviderTy valobj_provider) {
|
|
|
|
assert(m_parser_vars.get());
|
|
|
|
assert(valobj);
|
|
|
|
|
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
|
|
|
|
|
|
|
Value var_location = valobj->GetValue();
|
|
|
|
|
|
|
|
TypeFromUser user_type = valobj->GetCompilerType();
|
|
|
|
|
|
|
|
TypeSystemClang *clang_ast =
|
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(user_type.GetTypeSystem());
|
|
|
|
|
|
|
|
if (!clang_ast) {
|
|
|
|
LLDB_LOG(log, "Skipped a definition because it has no Clang AST");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
TypeFromParser parser_type = GuardedCopyType(user_type);
|
|
|
|
|
|
|
|
if (!parser_type) {
|
|
|
|
LLDB_LOG(log,
|
|
|
|
"Couldn't copy a variable's type into the parser's AST context");
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (var_location.GetContextType() == Value::ContextType::Invalid)
|
|
|
|
var_location.SetCompilerType(parser_type);
|
|
|
|
|
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
AddExpressionVariable(context, parser_type, valobj);
|
|
|
|
|
|
|
|
if (!parser_vars)
|
|
|
|
return;
|
|
|
|
|
2022-06-17 09:26:01 -07:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Found variable {0}, returned\n{1} (original {2})",
|
2022-07-12 09:40:12 +01:00
|
|
|
context.m_decl_name, ClangUtil::DumpDecl(parser_vars->m_named_decl),
|
|
|
|
ClangUtil::ToString(user_type));
|
|
|
|
|
|
|
|
parser_vars->m_llvm_value = nullptr;
|
|
|
|
parser_vars->m_lldb_value = std::move(var_location);
|
|
|
|
parser_vars->m_lldb_valobj_provider = std::move(valobj_provider);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ClangExpressionDeclMap::AddOneVariable(NameSearchContext &context,
|
|
|
|
VariableSP var,
|
|
|
|
ValueObjectSP valobj) {
|
|
|
|
assert(m_parser_vars.get());
|
|
|
|
|
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
|
|
|
|
|
|
|
TypeFromUser ut;
|
|
|
|
TypeFromParser pt;
|
|
|
|
Value var_location;
|
|
|
|
|
|
|
|
if (!GetVariableValue(var, var_location, &ut, &pt))
|
|
|
|
return;
|
|
|
|
|
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
AddExpressionVariable(context, pt, std::move(valobj));
|
|
|
|
|
|
|
|
if (!parser_vars)
|
|
|
|
return;
|
|
|
|
|
|
|
|
LLDB_LOG(log, " CEDM::FEVD Found variable {0}, returned\n{1} (original {2})",
|
|
|
|
context.m_decl_name, ClangUtil::DumpDecl(parser_vars->m_named_decl),
|
|
|
|
ClangUtil::ToString(ut));
|
|
|
|
|
|
|
|
parser_vars->m_llvm_value = nullptr;
|
|
|
|
parser_vars->m_lldb_value = var_location;
|
|
|
|
parser_vars->m_lldb_var = var;
|
2010-06-22 23:46:24 +00:00
|
|
|
}
|
|
|
|
|
2010-08-11 03:57:18 +00:00
|
|
|
void ClangExpressionDeclMap::AddOneVariable(NameSearchContext &context,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
ExpressionVariableSP &pvar_sp) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions.
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
2015-09-17 22:23:34 +00:00
|
|
|
TypeFromUser user_type(
|
|
|
|
llvm::cast<ClangExpressionVariable>(pvar_sp.get())->GetTypeFromUser());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-01-15 23:29:36 +00:00
|
|
|
TypeFromParser parser_type(GuardedCopyType(user_type));
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2011-12-01 21:04:37 +00:00
|
|
|
if (!parser_type.GetOpaqueQualType()) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Couldn't import type for pvar {0}",
|
|
|
|
pvar_sp->GetName());
|
2016-09-06 20:57:50 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
NamedDecl *var_decl =
|
TypeSystem is now a plugin interface and removed any "ClangASTContext &Class::GetClangASTContext()" functions.
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
2015-09-17 22:23:34 +00:00
|
|
|
context.AddVarDecl(parser_type.GetLValueReferenceType());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-09-08 22:23:39 +00:00
|
|
|
llvm::cast<ClangExpressionVariable>(pvar_sp.get())
|
2013-01-15 23:29:36 +00:00
|
|
|
->EnableParserVars(GetParserID());
|
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
2011-10-29 19:50:43 +00:00
|
|
|
llvm::cast<ClangExpressionVariable>(pvar_sp.get())
|
2013-01-15 23:29:36 +00:00
|
|
|
->GetParserVars(GetParserID());
|
|
|
|
parser_vars->m_named_decl = var_decl;
|
[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 11:14:47 +00:00
|
|
|
parser_vars->m_llvm_value = nullptr;
|
2013-07-11 22:46:58 +00:00
|
|
|
parser_vars->m_lldb_value.Clear();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-06-17 09:26:01 -07:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Added pvar {0}, returned\n{1}",
|
2019-11-25 13:27:51 +01:00
|
|
|
pvar_sp->GetName(), ClangUtil::DumpDecl(var_decl));
|
2010-08-11 03:57:18 +00:00
|
|
|
}
|
|
|
|
|
2014-07-06 17:54:58 +00:00
|
|
|
void ClangExpressionDeclMap::AddOneGenericVariable(NameSearchContext &context,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
const Symbol &symbol) {
|
2011-05-08 02:21:26 +00:00
|
|
|
assert(m_parser_vars.get());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-02-10 01:22:05 +00:00
|
|
|
Target *target = m_parser_vars->m_exe_ctx.GetTargetPtr();
|
2011-09-22 04:58:26 +00: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 11:14:47 +00:00
|
|
|
if (target == nullptr)
|
2013-07-11 22:46:58 +00:00
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2020-12-10 17:42:46 +01:00
|
|
|
TypeSystemClang *scratch_ast_context = GetScratchContext(*target);
|
2019-11-14 13:41:52 -08:00
|
|
|
if (!scratch_ast_context)
|
|
|
|
return;
|
2019-11-20 12:40:08 +01:00
|
|
|
|
|
|
|
TypeFromUser user_type(scratch_ast_context->GetBasicType(eBasicTypeVoid)
|
|
|
|
.GetPointerType()
|
|
|
|
.GetLValueReferenceType());
|
2019-11-29 13:02:41 +01:00
|
|
|
TypeFromParser parser_type(m_clang_ast_context->GetBasicType(eBasicTypeVoid)
|
2019-11-20 12:40:08 +01:00
|
|
|
.GetPointerType()
|
|
|
|
.GetLValueReferenceType());
|
2013-07-11 22:46:58 +00:00
|
|
|
NamedDecl *var_decl = context.AddVarDecl(parser_type);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-10-29 19:50:43 +00:00
|
|
|
std::string decl_name(context.m_decl_name.getAsString());
|
|
|
|
ConstString entity_name(decl_name.c_str());
|
2015-10-01 23:07:06 +00:00
|
|
|
ClangExpressionVariable *entity(new ClangExpressionVariable(
|
2011-10-29 19:50:43 +00:00
|
|
|
m_parser_vars->m_exe_ctx.GetBestExecutionContextScope(), entity_name,
|
2015-10-01 23:07:06 +00:00
|
|
|
user_type, m_parser_vars->m_target_info.byte_order,
|
|
|
|
m_parser_vars->m_target_info.address_byte_size));
|
|
|
|
m_found_entities.AddNewlyConstructedVariable(entity);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-15 23:29:36 +00:00
|
|
|
entity->EnableParserVars(GetParserID());
|
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
entity->GetParserVars(GetParserID());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
const Address symbol_address = symbol.GetAddress();
|
2011-09-22 04:58:26 +00:00
|
|
|
lldb::addr_t symbol_load_addr = symbol_address.GetLoadAddress(target);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2021-02-11 12:57:04 -08:00
|
|
|
// parser_vars->m_lldb_value.SetContext(Value::ContextType::ClangType,
|
2013-07-11 22:46:58 +00:00
|
|
|
// user_type.GetOpaqueQualType());
|
2015-08-24 23:46:31 +00:00
|
|
|
parser_vars->m_lldb_value.SetCompilerType(user_type);
|
2013-07-11 22:46:58 +00:00
|
|
|
parser_vars->m_lldb_value.GetScalar() = symbol_load_addr;
|
2021-02-11 12:57:04 -08:00
|
|
|
parser_vars->m_lldb_value.SetValueType(Value::ValueType::LoadAddress);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-01-15 23:29:36 +00:00
|
|
|
parser_vars->m_named_decl = var_decl;
|
[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 11:14:47 +00:00
|
|
|
parser_vars->m_llvm_value = nullptr;
|
2013-01-15 23:29:36 +00:00
|
|
|
parser_vars->m_lldb_sym = &symbol;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-06-17 09:26:01 -07:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Found variable {0}, returned\n{1}", decl_name,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
ClangUtil::DumpDecl(var_decl));
|
2011-05-08 02:21:26 +00:00
|
|
|
}
|
|
|
|
|
2010-12-14 02:59:59 +00:00
|
|
|
void ClangExpressionDeclMap::AddOneRegister(NameSearchContext &context,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
const RegisterInfo *reg_info) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-11-30 00:27:43 +00:00
|
|
|
CompilerType clang_type =
|
2019-11-29 13:43:23 +01:00
|
|
|
m_clang_ast_context->GetBuiltinTypeForEncodingAndBitSize(
|
|
|
|
reg_info->encoding, reg_info->byte_size * 8);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
if (!clang_type) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " Tried to add a type for {0}, but couldn't get one",
|
|
|
|
context.m_decl_name.getAsString());
|
2016-09-06 20:57:50 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
TypeFromParser parser_clang_type(clang_type);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
NamedDecl *var_decl = context.AddVarDecl(parser_clang_type);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-01 23:07:06 +00:00
|
|
|
ClangExpressionVariable *entity(new ClangExpressionVariable(
|
2011-10-29 19:50:43 +00:00
|
|
|
m_parser_vars->m_exe_ctx.GetBestExecutionContextScope(),
|
2015-10-01 23:07:06 +00:00
|
|
|
m_parser_vars->m_target_info.byte_order,
|
|
|
|
m_parser_vars->m_target_info.address_byte_size));
|
|
|
|
m_found_entities.AddNewlyConstructedVariable(entity);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-10-29 19:50:43 +00:00
|
|
|
std::string decl_name(context.m_decl_name.getAsString());
|
2013-07-11 22:46:58 +00:00
|
|
|
entity->SetName(ConstString(decl_name.c_str()));
|
2012-02-10 01:22:05 +00:00
|
|
|
entity->SetRegisterInfo(reg_info);
|
2013-07-11 22:46:58 +00:00
|
|
|
entity->EnableParserVars(GetParserID());
|
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
entity->GetParserVars(GetParserID());
|
2013-01-15 23:29:36 +00:00
|
|
|
parser_vars->m_named_decl = var_decl;
|
[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 11:14:47 +00:00
|
|
|
parser_vars->m_llvm_value = nullptr;
|
2013-07-11 22:46:58 +00:00
|
|
|
parser_vars->m_lldb_value.Clear();
|
2012-02-15 01:40:39 +00:00
|
|
|
entity->m_flags |= ClangExpressionVariable::EVBareRegister;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-06-17 09:26:01 -07:00
|
|
|
LLDB_LOG(log, " CEDM::FEVD Added register {0}, returned\n{1}",
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
context.m_decl_name.getAsString(), ClangUtil::DumpDecl(var_decl));
|
2010-11-30 00:27:43 +00:00
|
|
|
}
|
|
|
|
|
2011-05-18 22:01:49 +00:00
|
|
|
void ClangExpressionDeclMap::AddOneFunction(NameSearchContext &context,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
Function *function,
|
|
|
|
Symbol *symbol) {
|
2010-12-03 01:38:59 +00:00
|
|
|
assert(m_parser_vars.get());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2016-09-06 20:57:50 +00: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 11:14:47 +00:00
|
|
|
NamedDecl *function_decl = nullptr;
|
2015-06-25 21:46:34 +00:00
|
|
|
Address fun_address;
|
2015-08-11 22:53:00 +00:00
|
|
|
CompilerType function_clang_type;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-02-27 20:13:38 +00:00
|
|
|
bool is_indirect_function = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
if (function) {
|
|
|
|
Type *function_type = function->GetType();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-12-19 17:22:44 +00:00
|
|
|
const auto lang = function->GetCompileUnit()->GetLanguage();
|
|
|
|
const auto name = function->GetMangled().GetMangledName().AsCString();
|
|
|
|
const bool extern_c = (Language::LanguageIsC(lang) &&
|
|
|
|
!CPlusPlusLanguage::IsCPPMangledName(name)) ||
|
|
|
|
(Language::LanguageIsObjC(lang) &&
|
|
|
|
!Language::LanguageIsCPlusPlus(lang));
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-02-13 00:01:46 +00:00
|
|
|
if (!extern_c) {
|
|
|
|
TypeSystem *type_system = function->GetDeclContext().GetTypeSystem();
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
if (llvm::isa<TypeSystemClang>(type_system)) {
|
2016-02-13 00:01:46 +00:00
|
|
|
clang::DeclContext *src_decl_context =
|
|
|
|
(clang::DeclContext *)function->GetDeclContext()
|
|
|
|
.GetOpaqueDeclContext();
|
|
|
|
clang::FunctionDecl *src_function_decl =
|
|
|
|
llvm::dyn_cast_or_null<clang::FunctionDecl>(src_decl_context);
|
2017-05-11 22:08:05 +00:00
|
|
|
if (src_function_decl &&
|
|
|
|
src_function_decl->getTemplateSpecializationInfo()) {
|
|
|
|
clang::FunctionTemplateDecl *function_template =
|
|
|
|
src_function_decl->getTemplateSpecializationInfo()->getTemplate();
|
|
|
|
clang::FunctionTemplateDecl *copied_function_template =
|
|
|
|
llvm::dyn_cast_or_null<clang::FunctionTemplateDecl>(
|
2017-09-28 20:20:25 +00:00
|
|
|
CopyDecl(function_template));
|
2017-05-11 22:08:05 +00:00
|
|
|
if (copied_function_template) {
|
|
|
|
if (log) {
|
|
|
|
StreamString ss;
|
2019-07-23 21:14:23 +00:00
|
|
|
|
2017-05-11 22:08:05 +00:00
|
|
|
function->DumpSymbolContext(&ss);
|
2019-07-23 21:14:23 +00:00
|
|
|
|
2019-11-25 13:27:51 +01:00
|
|
|
LLDB_LOG(log,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
" CEDM::FEVD Imported decl for function template"
|
2022-06-17 09:26:01 -07:00
|
|
|
" {0} (description {1}), returned\n{2}",
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
copied_function_template->getNameAsString(),
|
2019-11-25 13:27:51 +01:00
|
|
|
ss.GetData(),
|
|
|
|
ClangUtil::DumpDecl(copied_function_template));
|
2017-05-11 22:08:05 +00:00
|
|
|
}
|
2019-07-23 21:14:23 +00:00
|
|
|
|
2017-05-11 22:08:05 +00:00
|
|
|
context.AddNamedDecl(copied_function_template);
|
|
|
|
}
|
|
|
|
} else if (src_function_decl) {
|
2016-02-13 00:01:46 +00:00
|
|
|
if (clang::FunctionDecl *copied_function_decl =
|
|
|
|
llvm::dyn_cast_or_null<clang::FunctionDecl>(
|
2019-07-23 21:14:23 +00:00
|
|
|
CopyDecl(src_function_decl))) {
|
2016-02-13 00:01:46 +00:00
|
|
|
if (log) {
|
|
|
|
StreamString ss;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-02-13 00:01:46 +00:00
|
|
|
function->DumpSymbolContext(&ss);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-25 13:27:51 +01:00
|
|
|
LLDB_LOG(log,
|
2022-06-17 09:26:01 -07:00
|
|
|
" CEDM::FEVD Imported decl for function {0} "
|
|
|
|
"(description {1}), returned\n{2}",
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
copied_function_decl->getNameAsString(), ss.GetData(),
|
|
|
|
ClangUtil::DumpDecl(copied_function_decl));
|
2016-02-13 00:01:46 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2011-10-14 20:34:21 +00:00
|
|
|
context.AddNamedDecl(copied_function_decl);
|
2010-07-27 00:55:47 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " Failed to import the function decl for '{0}'",
|
|
|
|
src_function_decl->getName());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-07-27 00:55:47 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-08-24 23:46:31 +00:00
|
|
|
if (!function_type) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " Skipped a function because it has no type");
|
2015-08-24 23:46:31 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2011-10-14 20:34:21 +00:00
|
|
|
function_clang_type = function_type->GetFullCompilerType();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
if (!function_clang_type) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " Skipped a function because it has no Clang type");
|
2015-06-25 21:46:34 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2016-02-13 00:01:46 +00:00
|
|
|
fun_address = function->GetAddressRange().GetBaseAddress();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
CompilerType copied_function_type = GuardedCopyType(function_clang_type);
|
|
|
|
if (copied_function_type) {
|
2013-04-24 00:34:41 +00:00
|
|
|
function_decl = context.AddFunDecl(copied_function_type, extern_c);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-05-01 00:47:29 +00:00
|
|
|
if (!function_decl) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " Failed to create a function decl for '{0}' ({1:x})",
|
|
|
|
function_type->GetName(), function_type->GetID());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-06-22 23:46:24 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
} else {
|
2011-10-20 00:47:21 +00:00
|
|
|
// We failed to copy the type we found
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log,
|
|
|
|
" Failed to import the function type '{0}' ({1:x})"
|
|
|
|
" into the expression parser AST contenxt",
|
|
|
|
function_type->GetName(), function_type->GetID());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
|
|
|
return;
|
2010-06-22 23:46:24 +00:00
|
|
|
}
|
2010-07-27 00:55:47 +00:00
|
|
|
} else if (symbol) {
|
2015-06-25 21:46:34 +00:00
|
|
|
fun_address = symbol->GetAddress();
|
2013-07-11 22:46:58 +00:00
|
|
|
function_decl = context.AddGenericFunDecl();
|
2013-02-27 20:13:38 +00:00
|
|
|
is_indirect_function = symbol->IsIndirect();
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log, " AddOneFunction called with no function and no symbol");
|
2016-09-06 20:57:50 +00:00
|
|
|
return;
|
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2012-02-10 01:22:05 +00:00
|
|
|
Target *target = m_parser_vars->m_exe_ctx.GetTargetPtr();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-10-01 23:07:06 +00:00
|
|
|
lldb::addr_t load_addr =
|
|
|
|
fun_address.GetCallableLoadAddress(target, is_indirect_function);
|
2013-07-11 22:46:58 +00:00
|
|
|
|
|
|
|
ClangExpressionVariable *entity(new ClangExpressionVariable(
|
|
|
|
m_parser_vars->m_exe_ctx.GetBestExecutionContextScope(),
|
2015-08-24 23:46:31 +00:00
|
|
|
m_parser_vars->m_target_info.byte_order,
|
2013-07-11 22:46:58 +00:00
|
|
|
m_parser_vars->m_target_info.address_byte_size));
|
|
|
|
m_found_entities.AddNewlyConstructedVariable(entity);
|
|
|
|
|
|
|
|
std::string decl_name(context.m_decl_name.getAsString());
|
|
|
|
entity->SetName(ConstString(decl_name.c_str()));
|
|
|
|
entity->SetCompilerType(function_clang_type);
|
|
|
|
entity->EnableParserVars(GetParserID());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
ClangExpressionVariable::ParserVars *parser_vars =
|
|
|
|
entity->GetParserVars(GetParserID());
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
if (load_addr != LLDB_INVALID_ADDRESS) {
|
2021-02-11 12:57:04 -08:00
|
|
|
parser_vars->m_lldb_value.SetValueType(Value::ValueType::LoadAddress);
|
2015-06-25 21:46:34 +00:00
|
|
|
parser_vars->m_lldb_value.GetScalar() = load_addr;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else {
|
2015-06-25 21:46:34 +00:00
|
|
|
// We have to try finding a file address.
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
lldb::addr_t file_addr = fun_address.GetFileAddress();
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2021-02-11 12:57:04 -08:00
|
|
|
parser_vars->m_lldb_value.SetValueType(Value::ValueType::FileAddress);
|
2013-07-11 22:46:58 +00:00
|
|
|
parser_vars->m_lldb_value.GetScalar() = file_addr;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-07-11 22:46:58 +00:00
|
|
|
|
|
|
|
parser_vars->m_named_decl = function_decl;
|
[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 11:14:47 +00:00
|
|
|
parser_vars->m_llvm_value = nullptr;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2010-07-16 00:09:46 +00:00
|
|
|
if (log) {
|
2012-07-28 00:21:01 +00:00
|
|
|
StreamString ss;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-06-25 21:46:34 +00:00
|
|
|
fun_address.Dump(&ss,
|
|
|
|
m_parser_vars->m_exe_ctx.GetBestExecutionContextScope(),
|
|
|
|
Address::DumpStyleResolvedDescription);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2019-11-25 13:27:51 +01:00
|
|
|
LLDB_LOG(log,
|
2022-06-17 09:26:01 -07:00
|
|
|
" CEDM::FEVD Found {0} function {1} (description {2}), "
|
|
|
|
"returned\n{3}",
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
(function ? "specific" : "generic"), decl_name, ss.GetData(),
|
|
|
|
ClangUtil::DumpDecl(function_decl));
|
2010-10-15 22:48:33 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2010-08-04 01:02:13 +00:00
|
|
|
|
2021-06-11 14:51:17 +02:00
|
|
|
void ClangExpressionDeclMap::AddContextClassType(NameSearchContext &context,
|
|
|
|
const TypeFromUser &ut) {
|
2015-08-11 22:53:00 +00:00
|
|
|
CompilerType copied_clang_type = GuardedCopyType(ut);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2016-04-29 18:09:03 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
if (!copied_clang_type) {
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log,
|
|
|
|
"ClangExpressionDeclMap::AddThisType - Couldn't import the type");
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-10-23 21:45:02 +00:00
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
if (copied_clang_type.IsAggregateType() &&
|
|
|
|
copied_clang_type.GetCompleteType()) {
|
2019-11-29 13:02:41 +01:00
|
|
|
CompilerType void_clang_type =
|
|
|
|
m_clang_ast_context->GetBasicType(eBasicTypeVoid);
|
2015-08-11 22:53:00 +00:00
|
|
|
CompilerType void_ptr_clang_type = void_clang_type.GetPointerType();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-12-29 20:10:29 +01:00
|
|
|
CompilerType method_type = m_clang_ast_context->CreateFunctionType(
|
|
|
|
void_clang_type, &void_ptr_clang_type, 1, false, 0);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-09-24 05:15:53 +00:00
|
|
|
const bool is_virtual = false;
|
2021-06-11 14:51:17 +02:00
|
|
|
const bool is_static = false;
|
2010-09-24 05:15:53 +00:00
|
|
|
const bool is_inline = false;
|
2010-10-01 02:31:07 +00:00
|
|
|
const bool is_explicit = false;
|
2011-11-02 18:09:01 +00:00
|
|
|
const bool is_attr_used = true;
|
2011-11-02 01:38:59 +00:00
|
|
|
const bool is_artificial = false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-29 13:02:41 +01:00
|
|
|
CXXMethodDecl *method_decl = m_clang_ast_context->AddMethodToCXXRecordType(
|
|
|
|
copied_clang_type.GetOpaqueQualType(), "$__lldb_expr", nullptr,
|
|
|
|
method_type, lldb::eAccessPublic, is_virtual, is_static, is_inline,
|
|
|
|
is_explicit, is_attr_used, is_artificial);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-11-25 13:27:51 +01:00
|
|
|
LLDB_LOG(log,
|
|
|
|
" CEDM::AddThisType Added function $__lldb_expr "
|
|
|
|
"(description {0}) for this type\n{1}",
|
|
|
|
ClangUtil::ToString(copied_clang_type),
|
|
|
|
ClangUtil::DumpDecl(method_decl));
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2013-02-01 06:55:48 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
if (!copied_clang_type.IsValid())
|
2016-04-29 18:09:03 +00:00
|
|
|
return;
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2015-10-23 21:45:02 +00:00
|
|
|
TypeSourceInfo *type_source_info = m_ast_context->getTrivialTypeSourceInfo(
|
|
|
|
QualType::getFromOpaquePtr(copied_clang_type.GetOpaqueQualType()));
|
|
|
|
|
|
|
|
if (!type_source_info)
|
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-23 21:45:02 +00:00
|
|
|
// Construct a typedef type because if "*this" is a templated type we can't
|
|
|
|
// just return ClassTemplateSpecializationDecls in response to name queries.
|
|
|
|
// Using a typedef makes this much more robust.
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-23 21:45:02 +00:00
|
|
|
TypedefDecl *typedef_decl = TypedefDecl::Create(
|
|
|
|
*m_ast_context, m_ast_context->getTranslationUnitDecl(), SourceLocation(),
|
|
|
|
SourceLocation(), context.m_decl_name.getAsIdentifierInfo(),
|
|
|
|
type_source_info);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-10-23 21:45:02 +00:00
|
|
|
if (!typedef_decl)
|
2016-09-06 20:57:50 +00:00
|
|
|
return;
|
|
|
|
|
2015-10-23 21:45:02 +00:00
|
|
|
context.AddNamedDecl(typedef_decl);
|
2013-02-01 06:55:48 +00:00
|
|
|
}
|
|
|
|
|
2014-07-06 17:54:58 +00:00
|
|
|
void ClangExpressionDeclMap::AddOneType(NameSearchContext &context,
|
[lldb] Remove all the 'current_id' logging counters from the lookup code.
Summary:
We have a lot of code in our lookup code to pass around `current_id` counters which end up in our logs like this:
```
AOCTV::FT [234] Found XYZ
```
This patch removes all of this code because:
* I'm splitting up all humongous functions, so I need to write more and more boilerplate to pass around these ids.
* I never saw any similar counters in the LLDB/LLVM code base.
* They're essentially globals and the last thing we need in LLDB is even more global state.
* They're not really useful when readings logs. It doesn't help that there isn't just 1 or 2 counters, but 12 (!) unique counters. I always thought that if I see two identical counter values in those brackets it's the same lookup request, but it seems that's only true by accident (and you can't know which of the 12 counters is actually printed without reading the code). The only time I know I can trust the counters is when it's obvious from the log that it's the same counter like in the log below, but then why have the counters in the first place?
```
LayoutRecordType[28] on (ASTContext*)0x00007FFA1C840200 'scratch ASTContext' for (RecordDecl*)0x00007FFA0AAE8CF0 [name = '__tree']
LRT[28] returned:
LRT[28] Original = (RecordDecl*)%p
LRT[28] Size = %lld
LRT[28] Alignment = %lld
LRT[28] Fields:
LRT[28] (FieldDecl*)0x00007FFA1A13B1D0, Name = '__begin_node_', Offset = 0 bits
LRT[28] (FieldDecl*)0x00007FFA1C08FD30, Name = '__pair1_', Offset = 64 bits
LRT[28] (FieldDecl*)0x00007FFA1C061210, Name = '__pair3_', Offset = 128 bits
LRT[28] Bases:
```
Reviewers: labath, shafik, JDevlieghere
Reviewed By: labath, shafik, JDevlieghere
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74951
2020-02-24 08:38:44 +01:00
|
|
|
const TypeFromUser &ut) {
|
2015-08-11 22:53:00 +00:00
|
|
|
CompilerType copied_clang_type = GuardedCopyType(ut);
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
if (!copied_clang_type) {
|
2022-01-31 15:57:48 +01:00
|
|
|
Log *log = GetLog(LLDBLog::Expressions);
|
2013-02-01 06:55:48 +00:00
|
|
|
|
2020-02-25 11:49:36 +01:00
|
|
|
LLDB_LOG(log,
|
|
|
|
"ClangExpressionDeclMap::AddOneType - Couldn't import the type");
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-02-01 06:55:48 +00:00
|
|
|
return;
|
|
|
|
}
|
2014-07-06 17:54:58 +00:00
|
|
|
|
2013-07-11 22:46:58 +00:00
|
|
|
context.AddTypeDecl(copied_clang_type);
|
2010-08-04 01:02:13 +00:00
|
|
|
}
|