[Lldb-commits] [PATCH] D51967: [PDB] Use the raw PDB symbol interface more accurately
aleksandr.urakov added a comment. That would be great, thank you! https://reviews.llvm.org/D51967 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D51967: [PDB] Use the raw PDB symbol interface more accurately
This revision was automatically updated to reflect the committed changes.
Closed by commit rL342208: [PDB] Use the raw PDB symbol interface more
accurately (authored by aleksandr.urakov, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D51967?vs=165231&id=165434#toc
Repository:
rL LLVM
https://reviews.llvm.org/D51967
Files:
lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
Index: lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
@@ -269,23 +269,49 @@
GetClassOrFunctionParent(const llvm::pdb::PDBSymbol &symbol) {
const IPDBSession &session = symbol.getSession();
const IPDBRawSymbol &raw = symbol.getRawSymbol();
+ auto tag = symbol.getSymTag();
- auto class_parent_id = raw.getClassParentId();
- if (auto class_parent = session.getSymbolById(class_parent_id))
-return class_parent;
-
- auto lexical_parent_id = raw.getLexicalParentId();
- auto lexical_parent = session.getSymbolById(lexical_parent_id);
- if (!lexical_parent)
-return nullptr;
+ // For items that are nested inside of a class, return the class that it is
+ // nested inside of.
+ // Note that only certain items can be nested inside of classes.
+ switch (tag) {
+ case PDB_SymType::Function:
+ case PDB_SymType::Data:
+ case PDB_SymType::UDT:
+ case PDB_SymType::Enum:
+ case PDB_SymType::FunctionSig:
+ case PDB_SymType::Typedef:
+ case PDB_SymType::BaseClass:
+ case PDB_SymType::VTable: {
+auto class_parent_id = raw.getClassParentId();
+if (auto class_parent = session.getSymbolById(class_parent_id))
+ return class_parent;
+ }
+ default:
+break;
+ }
- auto lexical_parent_tag = lexical_parent->getSymTag();
- if (lexical_parent_tag == PDB_SymType::Function)
-return lexical_parent;
- if (lexical_parent_tag == PDB_SymType::Exe)
-return nullptr;
+ // Otherwise, if it is nested inside of a function, return the function.
+ // Note that only certain items can be nested inside of functions.
+ switch (tag) {
+ case PDB_SymType::Block:
+ case PDB_SymType::Data: {
+auto lexical_parent_id = raw.getLexicalParentId();
+auto lexical_parent = session.getSymbolById(lexical_parent_id);
+if (!lexical_parent)
+ return nullptr;
+
+auto lexical_parent_tag = lexical_parent->getSymTag();
+if (lexical_parent_tag == PDB_SymType::Function)
+ return lexical_parent;
+if (lexical_parent_tag == PDB_SymType::Exe)
+ return nullptr;
- return GetClassOrFunctionParent(*lexical_parent);
+return GetClassOrFunctionParent(*lexical_parent);
+ }
+ default:
+return nullptr;
+ }
}
static clang::NamedDecl *
Index: lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp
@@ -269,23 +269,49 @@
GetClassOrFunctionParent(const llvm::pdb::PDBSymbol &symbol) {
const IPDBSession &session = symbol.getSession();
const IPDBRawSymbol &raw = symbol.getRawSymbol();
+ auto tag = symbol.getSymTag();
- auto class_parent_id = raw.getClassParentId();
- if (auto class_parent = session.getSymbolById(class_parent_id))
-return class_parent;
-
- auto lexical_parent_id = raw.getLexicalParentId();
- auto lexical_parent = session.getSymbolById(lexical_parent_id);
- if (!lexical_parent)
-return nullptr;
+ // For items that are nested inside of a class, return the class that it is
+ // nested inside of.
+ // Note that only certain items can be nested inside of classes.
+ switch (tag) {
+ case PDB_SymType::Function:
+ case PDB_SymType::Data:
+ case PDB_SymType::UDT:
+ case PDB_SymType::Enum:
+ case PDB_SymType::FunctionSig:
+ case PDB_SymType::Typedef:
+ case PDB_SymType::BaseClass:
+ case PDB_SymType::VTable: {
+auto class_parent_id = raw.getClassParentId();
+if (auto class_parent = session.getSymbolById(class_parent_id))
+ return class_parent;
+ }
+ default:
+break;
+ }
- auto lexical_parent_tag = lexical_parent->getSymTag();
- if (lexical_parent_tag == PDB_SymType::Function)
-return lexical_parent;
- if (lexical_parent_tag == PDB_SymType::Exe)
-return nullptr;
+ // Otherwise, if it is nested inside of a function, return the function.
+ // Note that only certain items can be nested inside of functions.
+ switch (tag) {
+ case PDB_SymType::Block:
+ case PDB_SymType::Data: {
+auto lexical_parent_id = raw.getLexicalParentId();
+auto lexical_parent = session.getSymbolById(lexical_parent_id);
+if (!lexical_parent)
+ return nullptr;
+
+auto lexical_parent_tag = lexical_parent->getSymTag();
+if (lexical_parent_tag == PDB_SymType::Function)
+
[Lldb-commits] [lldb] r342208 - [PDB] Use the raw PDB symbol interface more accurately
Author: aleksandr.urakov Date: Fri Sep 14 00:46:06 2018 New Revision: 342208 URL: http://llvm.org/viewvc/llvm-project?rev=342208&view=rev Log: [PDB] Use the raw PDB symbol interface more accurately Summary: This patch adds some symbol tag checks before using the `IPDBRawSymbol` interface to improve safety and readability. Reviewers: zturner Reviewed By: zturner Subscribers: lldb-commits, stella.stamenova Tags: #lldb Differential Revision: https://reviews.llvm.org/D51967 Modified: lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp Modified: lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp?rev=342208&r1=342207&r2=342208&view=diff == --- lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp (original) +++ lldb/trunk/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp Fri Sep 14 00:46:06 2018 @@ -269,23 +269,49 @@ static std::unique_ptrgetSymTag(); - if (lexical_parent_tag == PDB_SymType::Function) -return lexical_parent; - if (lexical_parent_tag == PDB_SymType::Exe) -return nullptr; +auto lexical_parent_tag = lexical_parent->getSymTag(); +if (lexical_parent_tag == PDB_SymType::Function) + return lexical_parent; +if (lexical_parent_tag == PDB_SymType::Exe) + return nullptr; - return GetClassOrFunctionParent(*lexical_parent); +return GetClassOrFunctionParent(*lexical_parent); + } + default: +return nullptr; + } } static clang::NamedDecl * ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D48802: [lldb-mi] Re-implement symbol-list-lines command.
tatyana-krasnukha added a comment.
symbol-list-lines.test fails on Linux too, input is compiled with gcc.
Comment at: lldb/trunk/lit/tools/lldb-mi/symbol/inputs/symbol-list-lines.c:6
+ return 0;
+}
The check doesn't count this line
Comment at: lldb/trunk/lit/tools/lldb-mi/symbol/symbol-list-lines.test:14
+-symbol-list-lines symbol-list-lines.c
+# CHECK:
^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="3"},{pc="0x{{[0-9A-Fa-f]+}}",line="4"},{pc="0x{{[0-9A-Fa-f]+}}",line="5"}]
+
here
Repository:
rL LLVM
https://reviews.llvm.org/D48802
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49739: Add new API to SBTarget class
teemperor added a comment. This test is timing out for me on Arch Linux. Any idea why? bash -x ./tools/lldb/lit/tools/lldb-mi/target/Output/target-select-so-path.test.script + set -o pipefail + set -x + : 'RUN: at line 3' + /data/llvm/dbg-build/./bin/clang -o /data/llvm/dbg-build/tools/lldb/lit/tools/lldb-mi/target/Output/target-select-so-path.test.tmp /home/me/llvm/llvm/tools/lldb/lit/tools/lldb-mi/target/inputs/main.c -g + : 'RUN: at line 4' + python /home/me/llvm/llvm/tools/lldb/lit/tools/lldb-mi/target/inputs/target-select-so-path.py '/data/llvm/dbg-build/bin/lldb-server gdbserver' '/data/llvm/dbg-build/bin/lldb-mi --synchronous /data/llvm/dbg-build/tools/lldb/lit/tools/lldb-mi/target/Output/target-select-so-path.test.tmp' /home/me/llvm/llvm/tools/lldb/lit/tools/lldb-mi/target/target-select-so-path.test failed to write to the unnamed pipe: timed out Repository: rL LLVM https://reviews.llvm.org/D49739 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52101: [lldb-mi] Correct regex in the symbol-list-lines test
apolyakov created this revision.
apolyakov added reviewers: tatyana-krasnukha, aprantl, clayborg.
Herald added a subscriber: ki.stfu.
The test failed in case of compiling a test suite with
gcc (checked versions are 5.2.0 and 7.3.0) because it
adds one more line entry comparing to clang. It doesn't
break the test's logic, so I just added a regex that matches
this case.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52101
Files:
lit/tools/lldb-mi/symbol/symbol-list-lines.test
Index: lit/tools/lldb-mi/symbol/symbol-list-lines.test
===
--- lit/tools/lldb-mi/symbol/symbol-list-lines.test
+++ lit/tools/lldb-mi/symbol/symbol-list-lines.test
@@ -14,7 +14,7 @@
# CHECK: ^error,msg="File Handler. Invalid file name path"
-symbol-list-lines symbol-list-lines.c
-# CHECK:
^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="3"},{pc="0x{{[0-9A-Fa-f]+}}",line="4"},{pc="0x{{[0-9A-Fa-f]+}}",line="5"}]
+# CHECK:
^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="3"},{pc="0x{{[0-9A-Fa-f]+}}",line="4"},{pc="0x{{[0-9A-Fa-f]+}}",line="5"}{{.*}}]
-symbol-list-lines list-lines-helper.c
-# CHECK:
^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="1"},{pc="0x{{[0-9A-Fa-f]+}}",line="2"},{pc="0x{{[0-9A-Fa-f]+}}",line="3"}]
+# CHECK:
^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="1"},{pc="0x{{[0-9A-Fa-f]+}}",line="2"},{pc="0x{{[0-9A-Fa-f]+}}",line="3"}{{.*}}]
Index: lit/tools/lldb-mi/symbol/symbol-list-lines.test
===
--- lit/tools/lldb-mi/symbol/symbol-list-lines.test
+++ lit/tools/lldb-mi/symbol/symbol-list-lines.test
@@ -14,7 +14,7 @@
# CHECK: ^error,msg="File Handler. Invalid file name path"
-symbol-list-lines symbol-list-lines.c
-# CHECK: ^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="3"},{pc="0x{{[0-9A-Fa-f]+}}",line="4"},{pc="0x{{[0-9A-Fa-f]+}}",line="5"}]
+# CHECK: ^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="3"},{pc="0x{{[0-9A-Fa-f]+}}",line="4"},{pc="0x{{[0-9A-Fa-f]+}}",line="5"}{{.*}}]
-symbol-list-lines list-lines-helper.c
-# CHECK: ^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="1"},{pc="0x{{[0-9A-Fa-f]+}}",line="2"},{pc="0x{{[0-9A-Fa-f]+}}",line="3"}]
+# CHECK: ^done,lines=[{pc="0x{{[0-9A-Fa-f]+}}",line="1"},{pc="0x{{[0-9A-Fa-f]+}}",line="2"},{pc="0x{{[0-9A-Fa-f]+}}",line="3"}{{.*}}]
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52101: [lldb-mi] Correct regex in the symbol-list-lines test
apolyakov added a comment. I've created this revision to be sure that you don't think that this approach is some kind of hack. Repository: rLLDB LLDB https://reviews.llvm.org/D52101 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D51934: [target] Change target create's behavior wrt loading dependent files.
shafik added inline comments.
Comment at: source/Commands/CommandObjectTarget.cpp:153
+static OptionDefinition g_dependents_options[1] = {
+{LLDB_OPT_SET_1, false, "no-dependents", 'd',
+ OptionParser::eOptionalArgument, nullptr, g_dependents_enumaration, 0,
Should "no-dependents" be "default"?
Comment at: source/Commands/CommandObjectTarget.cpp:181
+const int short_option = g_dependents_options[option_idx].short_option;
+switch (short_option) {
+case 'd': {
Wouldn't an if/else make more sense here? I had to reread the description up
top before this made sense that `option_value` is doing the work here.
https://reviews.llvm.org/D51934
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52103: Add descriptions to completed expressions
teemperor created this revision.
teemperor added a reviewer: LLDB.
Herald added a subscriber: lldb-commits.
Completing inside the expression command now uses the new description API
to also provide additional information to the user. For now this information
are the types of variables/fields and the signatures of completed function
calls.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52103
Files:
packages/Python/lldbsuite/test/expression_command/completion/TestExprCompletion.py
source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -14,6 +14,7 @@
#include "clang/AST/ASTContext.h"
#include "clang/AST/ASTDiagnostic.h"
#include "clang/AST/ExternalASTSource.h"
+#include "clang/AST/PrettyPrinter.h"
#include "clang/Basic/DiagnosticIDs.h"
#include "clang/Basic/FileManager.h"
#include "clang/Basic/SourceLocation.h"
@@ -564,6 +565,9 @@
std::string m_expr;
unsigned m_position = 0;
CompletionRequest &m_request;
+ /// The printing policy we use when printing declarations for our completion
+ /// descriptions.
+ clang::PrintingPolicy m_desc_policy;
/// Returns true if the given character can be used in an identifier.
/// This also returns true for numbers because for completion we usually
@@ -638,10 +642,22 @@
/// @param[out] position
///The character position of the user cursor in the `expr` parameter.
///
- CodeComplete(CompletionRequest &request, std::string expr, unsigned position)
+ CodeComplete(CompletionRequest &request, clang::LangOptions ops,
+ std::string expr, unsigned position)
: CodeCompleteConsumer(CodeCompleteOptions(), false),
m_info(std::make_shared()), m_expr(expr),
-m_position(position), m_request(request) {}
+m_position(position), m_request(request), m_desc_policy(ops) {
+
+// Ensure that the printing policy is producing a description that is as
+// short as possible.
+m_desc_policy.SuppressScope = true;
+m_desc_policy.SuppressTagKeyword = true;
+m_desc_policy.FullyQualifiedName = false;
+m_desc_policy.TerseOutput = true;
+m_desc_policy.IncludeNewlines = false;
+m_desc_policy.UseVoidForZeroParams = false;
+m_desc_policy.Bool = true;
+ }
/// Deregisters and destroys this code-completion consumer.
virtual ~CodeComplete() {}
@@ -692,6 +708,7 @@
CodeCompletionResult &R = Results[I];
std::string ToInsert;
+ std::string Description;
// Handle the different completion kinds that come from the Sema.
switch (R.Kind) {
case CodeCompletionResult::RK_Declaration: {
@@ -705,10 +722,16 @@
ToInsert += "()";
else
ToInsert += "(";
-}
-// If we try to complete a namespace, then we can directly append
-// the '::'.
-if (const NamespaceDecl *N = dyn_cast(D)) {
+ raw_string_ostream OS(Description);
+ F->print(OS, m_desc_policy, false);
+ OS.flush();
+} else if (const VarDecl *V = dyn_cast(D)) {
+ Description = V->getType().getAsString(m_desc_policy);
+} else if (const FieldDecl *F = dyn_cast(D)) {
+ Description = F->getType().getAsString(m_desc_policy);
+} else if (const NamespaceDecl *N = dyn_cast(D)) {
+ // If we try to complete a namespace, then we can directly append
+ // the '::'.
if (!N->isAnonymousNamespace())
ToInsert += "::";
}
@@ -735,7 +758,7 @@
// with the kind of result the lldb API expects.
std::string CompletionSuggestion =
mergeCompletion(m_expr, m_position, ToInsert);
-m_request.AddCompletion(CompletionSuggestion);
+m_request.AddCompletion(CompletionSuggestion, Description);
}
}
}
@@ -773,7 +796,8 @@
// the LLVMUserExpression which exposes the right API. This should never fail
// as we always have a ClangUserExpression whenever we call this.
LLVMUserExpression &llvm_expr = *static_cast(&m_expr);
- CodeComplete CC(request, llvm_expr.GetUserText(), typed_pos);
+ CodeComplete CC(request, m_compiler->getLangOpts(), llvm_expr.GetUserText(),
+ typed_pos);
// We don't need a code generator for parsing.
m_code_generator.reset();
// Start parsing the expression with our custom code completion consumer.
Index: packages/Python/lldbsuite/test/expression_command/completion/TestExprCompletion.py
===
--- packages/Python/lldbsuite/test/expression_command/completion/TestExprCompletion.py
+++ packages/Python/lldbsuite/test/expression_command/completion/TestExprCompletion.py
@@ -195,6 +195,39 @@
sel
[Lldb-commits] [PATCH] D51520: Add libc++ data formatter for std::variant
shafik updated this revision to Diff 165536.
shafik added a comment.
Applying clang-format
https://reviews.llvm.org/D51520
Files:
lldb.xcodeproj/project.pbxproj
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/Makefile
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/main.cpp
source/Plugins/Language/CPlusPlus/CMakeLists.txt
source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
source/Plugins/Language/CPlusPlus/LibCxx.cpp
source/Plugins/Language/CPlusPlus/LibCxx.h
source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
source/Plugins/Language/CPlusPlus/LibCxxVariant.h
Index: source/Plugins/Language/CPlusPlus/LibCxxVariant.h
===
--- /dev/null
+++ source/Plugins/Language/CPlusPlus/LibCxxVariant.h
@@ -0,0 +1,31 @@
+//===-- LibCxxVariant.h ---*- C++
+//-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef liblldb_LibCxxVariant_h_
+#define liblldb_LibCxxVariant_h_
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/DataFormatters/TypeSummary.h"
+#include "lldb/DataFormatters/TypeSynthetic.h"
+#include "lldb/Utility/Stream.h"
+
+namespace lldb_private {
+namespace formatters {
+bool LibcxxVariantSummaryProvider(
+ValueObject &valobj, Stream &stream,
+const TypeSummaryOptions &options); // libc++ std::variant<>
+
+SyntheticChildrenFrontEnd *LibcxxVariantFrontEndCreator(CXXSyntheticChildren *,
+lldb::ValueObjectSP);
+
+} // namespace formatters
+} // namespace lldb_private
+
+#endif // liblldb_LibCxxVariant_h_
Index: source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
===
--- /dev/null
+++ source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
@@ -0,0 +1,273 @@
+//===-- LibCxxVariant.cpp --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "LibCxxVariant.h"
+#include "lldb/DataFormatters/FormattersHelpers.h"
+
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/ScopeExit.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+// libc++ variant implementation contains two members that we care about both
+// are contained in the __impl member.
+// - __index which tells us which of the variadic template types is the active
+// type for the variant
+// - __data is a variadic union which recursively contains itself as member
+// which refers to the tailing variadic types.
+// - __head which refers to the leading non pack type
+// - __value refers to the actual value contained
+// - __tail which refers to the remaining pack types
+//
+// e.g. given std::variant v1
+//
+// (lldb) frame var -R v1.__impl.__data
+//(... __union<... 0, int, double, char>) v1.__impl.__data = {
+// ...
+// __head = {
+//__value = ...
+// }
+// __tail = {
+// ...
+//__head = {
+// __value = ...
+//}
+//__tail = {
+//...
+// __head = {
+//__value = ...
+// ...
+//
+// So given
+// - __index equal to 0 the active value is contained in
+//
+// __data.__head.__value
+//
+// - __index equal to 1 the active value is contained in
+//
+// __data.__tail.__head.__value
+//
+// - __index equal to 2 the active value is contained in
+//
+// __data.__tail.__tail.__head.__value
+//
+
+namespace {
+// libc++ std::variant index could have one of three states
+// 1) VALID, we can obtain it and its not variant_npos
+// 2) INVALID, we can't obtain it or it is not a type we expect
+// 3) NPOS, its value is variant_npos which means the variant has no value
+enum class LibcxxVariantIndexValidity { VALID, INVALID, NPOS };
+
+LibcxxVariantIndexValidity
+LibcxxVariantGetIndexValidity(ValueObjectSP &impl_sp) {
+ ValueObjectSP index_sp(
+ impl_sp->GetChildMemberWithName(ConstString("__index"), true));
+
+ if (!index_sp)
+return LibcxxVariantIndexValidity::INVALID;
+
+ int64_t index_value = index_sp->GetValueAsSigned(0);
+
+ CompilerType index_compiler_type = index_sp->GetCompilerType();
+
+ // We are expecting two layers of typedefs before we obtain the basic type
+ // The next two checks verify this.
+ if (!index_compiler_type.IsTypedefType())
+return LibcxxVariantIndexValidity::INVALID;
+
+ if (!index_c
[Lldb-commits] [PATCH] D51520: Add libc++ data formatter for std::variant
teemperor requested changes to this revision. teemperor added a comment. This revision now requires changes to proceed. LibCxx.h/.cpp are still not clang-formatted. I ran clang-format over the patch and pushed it here that this patch doesn't get stuck on this minor detail: https://github.com/Teemperor/lldb/commit/1c5c2f8f5d5af00420559dee52c9155e5bc72518.diff https://reviews.llvm.org/D51520 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D51520: Add libc++ data formatter for std::variant
shafik added a comment. @teemperor Thanks for the catch! https://reviews.llvm.org/D51520 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D51520: Add libc++ data formatter for std::variant
shafik updated this revision to Diff 165540.
shafik added a comment.
Applying clang-format to files I missed earlier
https://reviews.llvm.org/D51520
Files:
lldb.xcodeproj/project.pbxproj
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/Makefile
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/TestDataFormatterLibcxxVariant.py
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/variant/main.cpp
source/Plugins/Language/CPlusPlus/CMakeLists.txt
source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
source/Plugins/Language/CPlusPlus/LibCxx.h
source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
source/Plugins/Language/CPlusPlus/LibCxxVariant.h
Index: source/Plugins/Language/CPlusPlus/LibCxxVariant.h
===
--- /dev/null
+++ source/Plugins/Language/CPlusPlus/LibCxxVariant.h
@@ -0,0 +1,31 @@
+//===-- LibCxxVariant.h ---*- C++
+//-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef liblldb_LibCxxVariant_h_
+#define liblldb_LibCxxVariant_h_
+
+#include "lldb/Core/ValueObject.h"
+#include "lldb/DataFormatters/TypeSummary.h"
+#include "lldb/DataFormatters/TypeSynthetic.h"
+#include "lldb/Utility/Stream.h"
+
+namespace lldb_private {
+namespace formatters {
+bool LibcxxVariantSummaryProvider(
+ValueObject &valobj, Stream &stream,
+const TypeSummaryOptions &options); // libc++ std::variant<>
+
+SyntheticChildrenFrontEnd *LibcxxVariantFrontEndCreator(CXXSyntheticChildren *,
+lldb::ValueObjectSP);
+
+} // namespace formatters
+} // namespace lldb_private
+
+#endif // liblldb_LibCxxVariant_h_
Index: source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
===
--- /dev/null
+++ source/Plugins/Language/CPlusPlus/LibCxxVariant.cpp
@@ -0,0 +1,273 @@
+//===-- LibCxxVariant.cpp --*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "LibCxxVariant.h"
+#include "lldb/DataFormatters/FormattersHelpers.h"
+
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/ScopeExit.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+// libc++ variant implementation contains two members that we care about both
+// are contained in the __impl member.
+// - __index which tells us which of the variadic template types is the active
+// type for the variant
+// - __data is a variadic union which recursively contains itself as member
+// which refers to the tailing variadic types.
+// - __head which refers to the leading non pack type
+// - __value refers to the actual value contained
+// - __tail which refers to the remaining pack types
+//
+// e.g. given std::variant v1
+//
+// (lldb) frame var -R v1.__impl.__data
+//(... __union<... 0, int, double, char>) v1.__impl.__data = {
+// ...
+// __head = {
+//__value = ...
+// }
+// __tail = {
+// ...
+//__head = {
+// __value = ...
+//}
+//__tail = {
+//...
+// __head = {
+//__value = ...
+// ...
+//
+// So given
+// - __index equal to 0 the active value is contained in
+//
+// __data.__head.__value
+//
+// - __index equal to 1 the active value is contained in
+//
+// __data.__tail.__head.__value
+//
+// - __index equal to 2 the active value is contained in
+//
+// __data.__tail.__tail.__head.__value
+//
+
+namespace {
+// libc++ std::variant index could have one of three states
+// 1) VALID, we can obtain it and its not variant_npos
+// 2) INVALID, we can't obtain it or it is not a type we expect
+// 3) NPOS, its value is variant_npos which means the variant has no value
+enum class LibcxxVariantIndexValidity { VALID, INVALID, NPOS };
+
+LibcxxVariantIndexValidity
+LibcxxVariantGetIndexValidity(ValueObjectSP &impl_sp) {
+ ValueObjectSP index_sp(
+ impl_sp->GetChildMemberWithName(ConstString("__index"), true));
+
+ if (!index_sp)
+return LibcxxVariantIndexValidity::INVALID;
+
+ int64_t index_value = index_sp->GetValueAsSigned(0);
+
+ CompilerType index_compiler_type = index_sp->GetCompilerType();
+
+ // We are expecting two layers of typedefs before we obtain the basic type
+ // The next two checks verify this.
+ if (!index_compiler_type.IsTypedefType())
+return LibcxxVariantIndexValidity::INVALID;
+
+ if (!index_compiler_type.GetTyped
[Lldb-commits] [PATCH] D51520: Add libc++ data formatter for std::variant
teemperor accepted this revision. teemperor added a comment. This revision is now accepted and ready to land. LGTM now, thanks for the patch! https://reviews.llvm.org/D51520 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52111: Make eSearchDepthFunction work for scripted resolvers
jingham created this revision.
jingham added a reviewer: clayborg.
Herald added a subscriber: lldb-commits.
I hadn't needed eSearchDepthFunction for anything so it was stubbed out. Greg
indicated he would be interested in using this for the scripted resolvers, so I
got it to work with this patch. I also added tests to make sure the filters
were doing the right thing for the Module, CU and Function depth searches.
Repository:
rLLDB LLDB
https://reviews.llvm.org/D52111
Files:
include/lldb/Core/SearchFilter.h
packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
source/Core/SearchFilter.cpp
Index: source/Core/SearchFilter.cpp
===
--- source/Core/SearchFilter.cpp
+++ source/Core/SearchFilter.cpp
@@ -14,6 +14,7 @@
#include "lldb/Core/ModuleList.h" // for ModuleList
#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/SymbolContext.h" // for SymbolContext
+#include "lldb/Symbol/SymbolVendor.h"
#include "lldb/Target/Target.h"
#include "lldb/Utility/ConstString.h" // for ConstString
#include "lldb/Utility/Status.h" // for Status
@@ -147,6 +148,15 @@
bool SearchFilter::CompUnitPasses(CompileUnit &compUnit) { return true; }
+bool SearchFilter::FunctionPasses(Function &function) {
+ // This is a slightly cheesy job, but since we don't have finer grained
+ // filters yet, just checking that the start address passes is probably
+ // good enough for the base class behavior.
+ Address addr = function.GetAddressRange().GetBaseAddress();
+ return AddressPasses(addr);
+}
+
+
uint32_t SearchFilter::GetFilterRequiredItems() {
return (lldb::SymbolContextItem)0;
}
@@ -311,8 +321,33 @@
return Searcher::eCallbackReturnContinue;
else if (shouldContinue == Searcher::eCallbackReturnStop)
return shouldContinue;
-} else if (searcher.GetDepth() == lldb::eSearchDepthFunction) {
- // FIXME Descend to block.
+} else {
+ // First make sure this compile unit's functions are parsed
+ // since CompUnit::ForeachFunction only iterates over already
+ // parsed functions.
+ SymbolVendor *sym_vendor = module_sp->GetSymbolVendor();
+ if (!sym_vendor)
+continue;
+ SymbolContext sym_ctx;
+ cu_sp->CalculateSymbolContext(&sym_ctx);
+ if (!sym_vendor->ParseCompileUnitFunctions(sym_ctx))
+continue;
+ // If we got any functions, use ForeachFunction to do the iteration.
+ cu_sp->ForeachFunction([&](const FunctionSP &func_sp) {
+if (!FunctionPasses(*func_sp.get()))
+ return false; // Didn't pass the filter, just keep going.
+if (searcher.GetDepth() == lldb::eSearchDepthFunction) {
+ SymbolContext matchingContext(m_target_sp, module_sp,
+cu_sp.get(), func_sp.get());
+ shouldContinue = searcher.SearchCallback(*this,
+ matchingContext,
+ nullptr, false);
+} else {
+ shouldContinue = DoFunctionIteration(func_sp.get(), context,
+ searcher);
+}
+return shouldContinue != Searcher::eCallbackReturnContinue;
+ });
}
}
}
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
===
--- packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
@@ -24,10 +24,9 @@
if sym_ctx.function.IsValid():
Resolver.got_files = 3
func_name = sym_ctx.function.GetName()
-print("got called with: ", func_name)
Resolver.func_list.append(func_name)
if sym_name == func_name:
- self.bkpt.AddLocations(func.GetStartAddress())
+ self.bkpt.AddLocation(sym_ctx.function.GetStartAddress())
return
if sym_ctx.module.IsValid():
Index: packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
===
--- packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
+++ packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
@@ -106,10 +106,35 @@
wrong.append(target.BreakpointCreateFromScript("resolver.Resolver", extra_args, module_list, file_list))
# one with the wrong file - also should not fire:
+file_list.Clear()
module_list.Clear()
file_
[Lldb-commits] [PATCH] D52111: Make eSearchDepthFunction work for scripted resolvers
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. Very nice. You got it right. Repository: rLLDB LLDB https://reviews.llvm.org/D52111 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r342259 - Make the eSearchDepthFunction searches work, add tests
Author: jingham
Date: Fri Sep 14 11:41:40 2018
New Revision: 342259
URL: http://llvm.org/viewvc/llvm-project?rev=342259&view=rev
Log:
Make the eSearchDepthFunction searches work, add tests
using the scripted breakpoint resolver.
Differential Revision: https://reviews.llvm.org/D52111
Modified:
lldb/trunk/include/lldb/Core/SearchFilter.h
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
lldb/trunk/source/Core/SearchFilter.cpp
Modified: lldb/trunk/include/lldb/Core/SearchFilter.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/SearchFilter.h?rev=342259&r1=342258&r2=342259&view=diff
==
--- lldb/trunk/include/lldb/Core/SearchFilter.h (original)
+++ lldb/trunk/include/lldb/Core/SearchFilter.h Fri Sep 14 11:41:40 2018
@@ -184,6 +184,18 @@ public:
virtual bool CompUnitPasses(CompileUnit &compUnit);
//--
+ /// Call this method with a Function to see if \a function passes the
+ /// filter.
+ ///
+ /// @param[in] function
+ ///The Functions to check against the filter.
+ ///
+ /// @return
+ ///\b true if \a function passes, and \b false otherwise.
+ //--
+ virtual bool FunctionPasses(Function &function);
+
+ //--
/// Call this method to do the search using the Searcher.
///
/// @param[in] searcher
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py?rev=342259&r1=342258&r2=342259&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
Fri Sep 14 11:41:40 2018
@@ -106,10 +106,35 @@ class TestScriptedResolver(TestBase):
wrong.append(target.BreakpointCreateFromScript("resolver.Resolver",
extra_args, module_list, file_list))
# one with the wrong file - also should not fire:
+file_list.Clear()
module_list.Clear()
file_list.Append(lldb.SBFileSpec("noFileOfThisName.xxx"))
wrong.append(target.BreakpointCreateFromScript("resolver.Resolver",
extra_args, module_list, file_list))
+# Now make sure the CU level iteration obeys the file filters:
+file_list.Clear()
+module_list.Clear()
+file_list.Append(lldb.SBFileSpec("no_such_file.xxx"))
+
wrong.append(target.BreakpointCreateFromScript("resolver.ResolverCUDepth",
extra_args, module_list, file_list))
+
+# And the Module filters:
+file_list.Clear()
+module_list.Clear()
+module_list.Append(lldb.SBFileSpec("NoSuchModule.dylib"))
+
wrong.append(target.BreakpointCreateFromScript("resolver.ResolverCUDepth",
extra_args, module_list, file_list))
+
+# Now make sure the Function level iteration obeys the file filters:
+file_list.Clear()
+module_list.Clear()
+file_list.Append(lldb.SBFileSpec("no_such_file.xxx"))
+
wrong.append(target.BreakpointCreateFromScript("resolver.ResolverFuncDepth",
extra_args, module_list, file_list))
+
+# And the Module filters:
+file_list.Clear()
+module_list.Clear()
+module_list.Append(lldb.SBFileSpec("NoSuchModule.dylib"))
+
wrong.append(target.BreakpointCreateFromScript("resolver.ResolverFuncDepth",
extra_args, module_list, file_list))
+
# Make sure these didn't get locations:
for i in range(0, len(wrong)):
self.assertEqual(wrong[i].GetNumLocations(), 0, "Breakpoint %d has
locations."%(i))
@@ -158,12 +183,11 @@ class TestScriptedResolver(TestBase):
self.assertTrue(bkpt.GetNumLocations() > 0, "ResolverBadDepth got no
locations.")
self.expect("script print resolver.Resolver.got_files", substrs=["2"],
msg="Was only passed modules")
-# Make a breakpoint that searches at function depth - FIXME: uncomment
this when I fix the function
-# depth search.
-#bkpt =
target.BreakpointCreateFromScript("resolver.ResolverFuncDepth", extra_args,
module_list, file_list)
-#self.assertTrue(bkpt.GetNumLocations() > 0, "ResolverFuncDepth got no
locations.")
-#self.expect("script print resolver.Resolver.got_files",
substrs=["3"], msg="Was only passed modules")
-#self.expect("script print
[Lldb-commits] [PATCH] D52111: Make eSearchDepthFunction work for scripted resolvers
This revision was automatically updated to reflect the committed changes.
Closed by commit rL342259: Make the eSearchDepthFunction searches work, add
tests (authored by jingham, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D52111?vs=165549&id=165557#toc
Repository:
rL LLVM
https://reviews.llvm.org/D52111
Files:
lldb/trunk/include/lldb/Core/SearchFilter.h
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
lldb/trunk/source/Core/SearchFilter.cpp
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/resolver.py
@@ -24,10 +24,9 @@
if sym_ctx.function.IsValid():
Resolver.got_files = 3
func_name = sym_ctx.function.GetName()
-print("got called with: ", func_name)
Resolver.func_list.append(func_name)
if sym_name == func_name:
- self.bkpt.AddLocations(func.GetStartAddress())
+ self.bkpt.AddLocation(sym_ctx.function.GetStartAddress())
return
if sym_ctx.module.IsValid():
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/scripted_bkpt/TestScriptedResolver.py
@@ -106,10 +106,35 @@
wrong.append(target.BreakpointCreateFromScript("resolver.Resolver", extra_args, module_list, file_list))
# one with the wrong file - also should not fire:
+file_list.Clear()
module_list.Clear()
file_list.Append(lldb.SBFileSpec("noFileOfThisName.xxx"))
wrong.append(target.BreakpointCreateFromScript("resolver.Resolver", extra_args, module_list, file_list))
+# Now make sure the CU level iteration obeys the file filters:
+file_list.Clear()
+module_list.Clear()
+file_list.Append(lldb.SBFileSpec("no_such_file.xxx"))
+wrong.append(target.BreakpointCreateFromScript("resolver.ResolverCUDepth", extra_args, module_list, file_list))
+
+# And the Module filters:
+file_list.Clear()
+module_list.Clear()
+module_list.Append(lldb.SBFileSpec("NoSuchModule.dylib"))
+wrong.append(target.BreakpointCreateFromScript("resolver.ResolverCUDepth", extra_args, module_list, file_list))
+
+# Now make sure the Function level iteration obeys the file filters:
+file_list.Clear()
+module_list.Clear()
+file_list.Append(lldb.SBFileSpec("no_such_file.xxx"))
+wrong.append(target.BreakpointCreateFromScript("resolver.ResolverFuncDepth", extra_args, module_list, file_list))
+
+# And the Module filters:
+file_list.Clear()
+module_list.Clear()
+module_list.Append(lldb.SBFileSpec("NoSuchModule.dylib"))
+wrong.append(target.BreakpointCreateFromScript("resolver.ResolverFuncDepth", extra_args, module_list, file_list))
+
# Make sure these didn't get locations:
for i in range(0, len(wrong)):
self.assertEqual(wrong[i].GetNumLocations(), 0, "Breakpoint %d has locations."%(i))
@@ -158,12 +183,11 @@
self.assertTrue(bkpt.GetNumLocations() > 0, "ResolverBadDepth got no locations.")
self.expect("script print resolver.Resolver.got_files", substrs=["2"], msg="Was only passed modules")
-# Make a breakpoint that searches at function depth - FIXME: uncomment this when I fix the function
-# depth search.
-#bkpt = target.BreakpointCreateFromScript("resolver.ResolverFuncDepth", extra_args, module_list, file_list)
-#self.assertTrue(bkpt.GetNumLocations() > 0, "ResolverFuncDepth got no locations.")
-#self.expect("script print resolver.Resolver.got_files", substrs=["3"], msg="Was only passed modules")
-#self.expect("script print resolver.Resolver.func_list", substrs=["break_on_me", "main", "test_func"], msg="Saw all the functions")
+# Make a breakpoint that searches at function depth:
+bkpt = target.BreakpointCreateFromScript("resolver.ResolverFuncDepth", extra_args, module_list, file_list)
+self.assertTrue(bkpt.GetNumLocations() > 0, "ResolverFuncDepth got no locations.")
+self.expect("script print resolver.Resolver.got_files", substrs=["3"], msg="Was only passed modules")
+self.expect("script print resolver.Resolver.func_list",
[Lldb-commits] [lldb] r342262 - [IRInterpreter] Fall back to JIT with 128-bit values.
Author: davide
Date: Fri Sep 14 11:55:31 2018
New Revision: 342262
URL: http://llvm.org/viewvc/llvm-project?rev=342262&view=rev
Log:
[IRInterpreter] Fall back to JIT with 128-bit values.
They're not that common, and falling back is definitely
better than throwing an error instead of the result. If we
feel motivated, we might end up implementing support for these,
but it's unclear whether it's worth the effort/complexity.
Fixes PR38925.
Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Makefile
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/main.c
Modified:
lldb/trunk/source/Expression/IRInterpreter.cpp
Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Makefile?rev=342262&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Makefile
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Makefile
Fri Sep 14 11:55:31 2018
@@ -0,0 +1,3 @@
+LEVEL = ../../make
+C_SOURCES := main.c
+include $(LEVEL)/Makefile.rules
Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py?rev=342262&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/Test128BitsInteger.py
Fri Sep 14 11:55:31 2018
@@ -0,0 +1,4 @@
+from lldbsuite.test import lldbinline
+from lldbsuite.test import decorators
+
+lldbinline.MakeInlineTest(__file__, globals(), None)
Added:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/main.c
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/main.c?rev=342262&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/main.c
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/rdar44436068/main.c
Fri Sep 14 11:55:31 2018
@@ -0,0 +1,8 @@
+int main(void)
+{
+__int128_t n = 1;
+n = n + n;
+return n; //%self.expect("p n", substrs=['(__int128_t) $0 = 2'])
+ //%self.expect("p n + 6", substrs=['(__int128) $1 = 8'])
+ //%self.expect("p n + n", substrs=['(__int128) $2 = 4'])
+}
Modified: lldb/trunk/source/Expression/IRInterpreter.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRInterpreter.cpp?rev=342262&r1=342261&r2=342262&view=diff
==
--- lldb/trunk/source/Expression/IRInterpreter.cpp (original)
+++ lldb/trunk/source/Expression/IRInterpreter.cpp Fri Sep 14 11:55:31 2018
@@ -613,6 +613,18 @@ bool IRInterpreter::CanInterpret(llvm::M
}
}
+// The IR interpreter currently doesn't know about
+// 128-bit integers. As they're not that frequent,
+// we can just fall back to the JIT rather than
+// choking.
+if (operand_type->getPrimitiveSizeInBits() > 64) {
+ if (log)
+log->Printf("Unsupported operand type: %s",
+PrintType(operand_type).c_str());
+ error.SetErrorString(unsupported_operand_error);
+ return false;
+}
+
if (Constant *constant = llvm::dyn_cast(operand)) {
if (!CanResolveConstant(constant)) {
if (log)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52101: [lldb-mi] Correct regex in the symbol-list-lines test
aprantl accepted this revision. aprantl added a comment. This revision is now accepted and ready to land. Thanks, that looks like a safe change. Repository: rLLDB LLDB https://reviews.llvm.org/D52101 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r342266 - Fix lldb-vscode README.md
Author: xiaobai Date: Fri Sep 14 12:41:20 2018 New Revision: 342266 URL: http://llvm.org/viewvc/llvm-project?rev=342266&view=rev Log: Fix lldb-vscode README.md Summary: The readme was missing "-" characters to enable links Patch by Nathan Lanza Differential Revision: https://reviews.llvm.org/D52069 Modified: lldb/trunk/tools/lldb-vscode/README.md Modified: lldb/trunk/tools/lldb-vscode/README.md URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-vscode/README.md?rev=342266&r1=342265&r2=342266&view=diff == --- lldb/trunk/tools/lldb-vscode/README.md (original) +++ lldb/trunk/tools/lldb-vscode/README.md Fri Sep 14 12:41:20 2018 @@ -2,15 +2,15 @@ # Table of Contents - [Introduction](#Introduction) -- [Intallation](#Intallation Visual Studio Code) +- [Installation](#Installation-Visual-Studio-Code) - [Configurations](#configurations) - - [Launch Configuration Settings](#launch configuration settings) - - [Attach Configuration Settings](#attach configuration settings) - - [Example configurations](#example configurations) + - [Launch Configuration Settings](#launch-configuration-settings) + - [Attach Configuration Settings](#attach-configuration-settings) + - [Example configurations](#example-configurations) - [Launching](#launching) - - [Attach to process using process ID](#attach using pid) - - [Attach to process by name](#attach by name) - - [Loading a core file](#loading a core file) + - [Attach to process using process ID](#attach-using-pid) + - [Attach to process by name](#attach-by-name) + - [Loading a core file](#loading-a-core-file) # Introduction @@ -20,7 +20,7 @@ It can be installed as an extension for The protocol is easy to run remotely and also can allow other tools and IDEs to get a full featured debugger with a well defined protocol. -# Intallation for Visual Studio Code +# Installation for Visual Studio Code Installing the plug-in involves creating a directory in the `~/.vscode/extensions` folder and copying the package.json file that is in the same directory as this documentation into it, and copying to symlinking a lldb-vscode binary into ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r342280 - [IRInterpreter] Minor cleanups, add comments. NFCI.
Author: davide
Date: Fri Sep 14 13:48:34 2018
New Revision: 342280
URL: http://llvm.org/viewvc/llvm-project?rev=342280&view=rev
Log:
[IRInterpreter] Minor cleanups, add comments. NFCI.
Modified:
lldb/trunk/source/Expression/IRInterpreter.cpp
Modified: lldb/trunk/source/Expression/IRInterpreter.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRInterpreter.cpp?rev=342280&r1=342279&r2=342280&view=diff
==
--- lldb/trunk/source/Expression/IRInterpreter.cpp (original)
+++ lldb/trunk/source/Expression/IRInterpreter.cpp Fri Sep 14 13:48:34 2018
@@ -601,17 +601,13 @@ bool IRInterpreter::CanInterpret(llvm::M
Value *operand = ii->getOperand(oi);
Type *operand_type = operand->getType();
-switch (operand_type->getTypeID()) {
-default:
- break;
-case Type::VectorTyID: {
+// Vectors are currently unsupported, give up.
+if (operand_type->getTypeID() == Type::VectorTyID)
if (log)
log->Printf("Unsupported operand type: %s",
PrintType(operand_type).c_str());
error.SetErrorString(unsupported_operand_error);
return false;
-}
-}
// The IR interpreter currently doesn't know about
// 128-bit integers. As they're not that frequent,
@@ -625,7 +621,7 @@ bool IRInterpreter::CanInterpret(llvm::M
return false;
}
-if (Constant *constant = llvm::dyn_cast(operand)) {
+if (auto *constant = llvm::dyn_cast(operand)) {
if (!CanResolveConstant(constant)) {
if (log)
log->Printf("Unsupported constant: %s",
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D52065: WWW docs for scripted breakpoint resolvers
clayborg added a comment. See inlined comments. Comment at: www/python-reference.html:324 + +Another use of the Python API's in lldb is to create a custom breakpoint resolver. This + allows you to implement your own logic to search the space of the code in a given Target Maybe specify the SVN revision this went in with just in case? If they try this with older LLDBs it won't work. Comment at: www/python-reference.html:340 + The Searcher can be provided with a SearchFilter that it will use to restrict this search. For instance, if the + SearchFilter specifies a list of good Modules, the Searcher will not recurse into Modules that aren't on the list. + Maybe mention if no modules are specified, it will search all? Comment at: www/python-reference.html:365 + will pass the search. However, you don't need to + handle this yourself. SBBreakpoint::AddLocation will only add locations that pass the Search Filter. + Might be good to specify the module and compile unit filter are handled outside of the python class? Not sure anyone will know. Might be good to specify that the only thing we need to write in python is the resolver, with the caveat of addresses getting rejected due to searcher. Comment at: www/python-reference.html:368-369 + + At present, when defining a new Breakpoint type, you can only provide a custom Resolver. Although you can't provide a custom + SearchFilter, the API's that allow the definition of new scripted breakpoint types do allow you to create Search Filters + specified by a list of Modules, CompileUnits, or both. Maybe have some create example commands and detail what options are for the searcher which is auto handled for us and what part is for the resolver? Repository: rLLDB LLDB https://reviews.llvm.org/D52065 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D50751: Allow use of self.filecheck in LLDB tests (c.f self.expect)
vsk updated this revision to Diff 165613.
vsk marked 6 inline comments as done.
vsk added a comment.
Herald added a subscriber: mgorny.
Sorry for the delay, I was busy with other work. I think I've addressed the
review feedback. PTAL.
https://reviews.llvm.org/D50751
Files:
lldb/CMakeLists.txt
lldb/lldb.xcodeproj/project.pbxproj
lldb/packages/Python/lldbsuite/test/configuration.py
lldb/packages/Python/lldbsuite/test/dotest.py
lldb/packages/Python/lldbsuite/test/dotest_args.py
lldb/packages/Python/lldbsuite/test/expression_command/formatters/TestFormatters.py
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/typedef_array/main.cpp
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/test/CMakeLists.txt
Index: lldb/test/CMakeLists.txt
===
--- lldb/test/CMakeLists.txt
+++ lldb/test/CMakeLists.txt
@@ -49,6 +49,7 @@
list(APPEND LLDB_TEST_COMMON_ARGS
--executable ${LLDB_TEST_EXECUTABLE}
--dsymutil ${LLDB_TEST_DSYMUTIL}
+ --filecheck ${LLDB_TEST_FILECHECK}
-C ${LLDB_TEST_C_COMPILER}
)
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -48,6 +48,7 @@
import signal
from subprocess import *
import sys
+import tempfile
import time
import traceback
import types
@@ -2214,6 +2215,54 @@
compare_string, msg=COMPLETION_MSG(
str_input, p, match_strings), exe=False, patterns=[p])
+def filecheck(
+self,
+command,
+check_file,
+filecheck_options = ''):
+# Run the command.
+self.runCmd(
+command,
+msg="FileCheck'ing result of `{0}`".format(command))
+
+# Get the error text if there was an error, and the regular text if not.
+output = self.res.GetOutput() if self.res.Succeeded() \
+else self.res.GetError()
+
+# Assemble the absolute path to the check file. As a convenience for
+# LLDB inline tests, assume that the check file is a relative path to
+# a file within the inline test directory.
+if check_file.endswith('.pyc'):
+check_file = check_file[:-1]
+if hasattr(self, 'test_filename'):
+check_file_abs = os.path.join(os.path.dirname(self.test_filename),
+check_file)
+else:
+check_file_abs = os.path.abspath(check_file)
+
+# Run FileCheck.
+filecheck_bin = configuration.get_filecheck_path()
+filecheck_args = [filecheck_bin, check_file_abs]
+if filecheck_options:
+filecheck_args.append(filecheck_options)
+subproc = Popen(filecheck_args, stdin=PIPE, stdout=PIPE, stderr=PIPE)
+cmd_stdout, cmd_stderr = subproc.communicate(input=output)
+cmd_status = subproc.returncode
+
+if cmd_status != 0:
+filecheck_cmd = " ".join(filecheck_args)
+self.assertTrue(cmd_status == 0, """
+--- FileCheck failed (code={0}) ---
+{1}
+
+FileCheck input:
+{2}
+
+FileCheck output:
+{3}
+{4}
+""".format(cmd_status, filecheck_cmd, output, cmd_stdout, cmd_stderr))
+
def expect(
self,
str,
Index: lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/typedef_array/main.cpp
===
--- lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/typedef_array/main.cpp
+++ lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/typedef_array/main.cpp
@@ -9,6 +9,11 @@
typedef int Foo;
int main() {
+// CHECK: (Foo [3]) array = {
+// CHECK-NEXT: (Foo) [0] = 1
+// CHECK-NEXT: (Foo) [1] = 2
+// CHECK-NEXT: (Foo) [2] = 3
+// CHECK-NEXT: }
Foo array[3] = {1,2,3};
-return 0; //% self.expect("frame variable array --show-types --", substrs = ['(Foo [3]) array = {','(Foo) [0] = 1','(Foo) [1] = 2','(Foo) [2] = 3'])
+return 0; //% self.filecheck("frame variable array --show-types --", 'main.cpp')
}
Index: lldb/packages/Python/lldbsuite/test/expression_command/formatters/TestFormatters.py
===
--- lldb/packages/Python/lldbsuite/test/expression_command/formatters/TestFormatters.py
+++ lldb/packages/Python/lldbsuite/test/expression_command/formatters/TestFormatters.py
@@ -57,14 +57,21 @@
self.runCmd("frame variable foo1.b --show-types")
self.runCmd("frame variable foo1.b.b_ref --show-types")
-self.expect(
-"expression --show-types -- *(new foo(47))",
-substrs=[
-'(int) a = 47',
-'(bar) b = {',
-'(int) i = 94',
-'(baz) b = {',
-'(int) k = 99'])
+
[Lldb-commits] [PATCH] D52065: WWW docs for scripted breakpoint resolvers
jingham updated this revision to Diff 165614. jingham added a comment. I think this should address your concerns, though I did so more by reworking the presentation, so you won't find inserts exactly at the places you pointed out. But I tried to make it clear that you only write the Resolver, and also gave more examples of how the SearchFilter gets provided. Repository: rLLDB LLDB https://reviews.llvm.org/D52065 Files: www/python-reference.html Index: www/python-reference.html === --- www/python-reference.html +++ www/python-reference.html @@ -316,6 +316,196 @@ + + + Using the Python API's to create custom breakpoints + + +Another use of the Python API's in lldb is to create a custom breakpoint resolver. This facility + was added in r51967. + + + It allows you to provide the algorithm which will be used in the breakpoint's + search of the space of the code in a given Target + to determine where to set the breakpoint locations - the actual places where the breakpoint will trigger. + To understand how this works you need to know a little about how lldb handles breakpoints. + + + In lldb, a breakpoint is composed of three parts, the Searcher, and the Resolver, which cooperate to determine + how breakpoint locations are set; and the the collection + of options which determine what happens when a location triggers. That last part includes the commands, + conditions, ignore counts, etc. All the options in this collection work identically for normal and scripted breakpoints, + so for our purposes only the Searcher and Resolver are relevant. + + + The Searcher's job is to traverse in a structured way the code in the current target. It + proceeds from the Target, to search all the Modules in the Target, in each Module it can recurse + into the Compile Units in that module, and within each Compile Unit it can recurse over the Functions + it contains. + + + The Searcher can be provided with a SearchFilter that it will use to restrict this search. For instance, if the + SearchFilter specifies a list of good Modules, the Searcher will not recurse into Modules that aren't on the list. + When you pass the -s modulename flag to break set you are creating a Module-based search filter. + When you pass -f filename.c to break set -n you are creating a file based search filter. If neither + of these is specified, the breakpoint will have a no-op search filter, so all parts of the program are searched + and all locations accepted. + + + The Resolver has two functions. The most important one is the callback it provides. This will get called at the appropriate time + in the course of the search. The callback is where the job of adding locations to the breakpoint gets done. + + + The other function is specifying to the Searcher at what depth in the above described recursion it wants to be + called. Setting a search depth also provides a stop for the recursion. For instance, if you request a Module depth + search, then the callback will be called for each Module as it gets added to the Target, but the searcher will not recurse into the + Compile Units in the module. + + + One other slight sublety is that the depth at which you get called back is not necessarily the depth at which the + the SearchFilter is specified. For instance, if you are doing symbol searches, it is convenient to use the Module + depth for the search, since symbols are stored in the module. + But the SearchFilter might specify some subset of CompileUnits, so not all the symbols you might find in each module + will pass the search. You don't need to + handle this situation yourself, since SBBreakpoint::AddLocation will only add locations that pass the Search Filter. + This API returns an SBError to inform you whether your location was added. + + + When the breakpoint is originally created, its Searcher will process all the currently loaded modules. + The Searcher will also visit any new modules as they are added to the target. This happens, for instance, when +
