[Lldb-commits] [lldb] 6abc387 - Revert "Fix the EditLine unittest build on Darwin after PR 92865"

2024-05-28 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-05-28T18:16:13-07:00
New Revision: 6abc3876c35bbe8fb5dd6435dc60f2c816b97ef6

URL: 
https://github.com/llvm/llvm-project/commit/6abc3876c35bbe8fb5dd6435dc60f2c816b97ef6
DIFF: 
https://github.com/llvm/llvm-project/commit/6abc3876c35bbe8fb5dd6435dc60f2c816b97ef6.diff

LOG: Revert "Fix the EditLine unittest build on Darwin after PR 92865"

This reverts commit 0380044e16a1c016e001a56c0ca7f4db649a6cae.

While I figure out some mysterious CMake error.

Added: 


Modified: 
lldb/unittests/CMakeLists.txt
lldb/unittests/Editline/CMakeLists.txt

Removed: 




diff  --git a/lldb/unittests/CMakeLists.txt b/lldb/unittests/CMakeLists.txt
index 728dec5006d6b..a2585a94b6155 100644
--- a/lldb/unittests/CMakeLists.txt
+++ b/lldb/unittests/CMakeLists.txt
@@ -51,13 +51,11 @@ if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
   # FIXME: APITests.exe is not a valid googletest binary.
   add_subdirectory(API)
 endif()
-if (NOT CMAKE_SYSTEM_NAME MATCHES "Darwin" OR LLDB_ENABLE_CURSES)
-  add_subdirectory(Editline)
-endif()
 add_subdirectory(Breakpoint)
 add_subdirectory(Core)
 add_subdirectory(DataFormatter)
 add_subdirectory(Disassembler)
+add_subdirectory(Editline)
 add_subdirectory(Expression)
 add_subdirectory(Host)
 add_subdirectory(Interpreter)

diff  --git a/lldb/unittests/Editline/CMakeLists.txt 
b/lldb/unittests/Editline/CMakeLists.txt
index f213bfd1ab581..4b2643d15c5fc 100644
--- a/lldb/unittests/Editline/CMakeLists.txt
+++ b/lldb/unittests/Editline/CMakeLists.txt
@@ -5,5 +5,4 @@ add_lldb_unittest(EditlineTests
 lldbHost
 lldbUtility
 LLVMTestingSupport
-${CURSES_LIBRARIES}
   )



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 0380044 - Fix the EditLine unittest build on Darwin after PR 92865

2024-05-28 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-05-28T17:47:08-07:00
New Revision: 0380044e16a1c016e001a56c0ca7f4db649a6cae

URL: 
https://github.com/llvm/llvm-project/commit/0380044e16a1c016e001a56c0ca7f4db649a6cae
DIFF: 
https://github.com/llvm/llvm-project/commit/0380044e16a1c016e001a56c0ca7f4db649a6cae.diff

LOG: Fix the EditLine unittest build on Darwin after PR 92865

There was a Darwin only use of setupterm (under USE_SETUPTERM_WORKAROUND)
that required libcurses.dylib.  That was added to the main build, but
not to the unittest.

Added: 


Modified: 
lldb/unittests/CMakeLists.txt
lldb/unittests/Editline/CMakeLists.txt

Removed: 




diff  --git a/lldb/unittests/CMakeLists.txt b/lldb/unittests/CMakeLists.txt
index a2585a94b6155..728dec5006d6b 100644
--- a/lldb/unittests/CMakeLists.txt
+++ b/lldb/unittests/CMakeLists.txt
@@ -51,11 +51,13 @@ if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
   # FIXME: APITests.exe is not a valid googletest binary.
   add_subdirectory(API)
 endif()
+if (NOT CMAKE_SYSTEM_NAME MATCHES "Darwin" OR LLDB_ENABLE_CURSES)
+  add_subdirectory(Editline)
+endif()
 add_subdirectory(Breakpoint)
 add_subdirectory(Core)
 add_subdirectory(DataFormatter)
 add_subdirectory(Disassembler)
-add_subdirectory(Editline)
 add_subdirectory(Expression)
 add_subdirectory(Host)
 add_subdirectory(Interpreter)

diff  --git a/lldb/unittests/Editline/CMakeLists.txt 
b/lldb/unittests/Editline/CMakeLists.txt
index 4b2643d15c5fc..f213bfd1ab581 100644
--- a/lldb/unittests/Editline/CMakeLists.txt
+++ b/lldb/unittests/Editline/CMakeLists.txt
@@ -5,4 +5,5 @@ add_lldb_unittest(EditlineTests
 lldbHost
 lldbUtility
 LLVMTestingSupport
+${CURSES_LIBRARIES}
   )



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] e6b2197 - Revert a test that was failing after a previous reversion.

2024-05-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-05-13T18:18:40-07:00
New Revision: e6b2197a89f5d6d0f56a03c03b8afda561eee899

URL: 
https://github.com/llvm/llvm-project/commit/e6b2197a89f5d6d0f56a03c03b8afda561eee899
DIFF: 
https://github.com/llvm/llvm-project/commit/e6b2197a89f5d6d0f56a03c03b8afda561eee899.diff

LOG: Revert a test that was failing after a previous reversion.

This test was modified as part of the commit:

9a7262c2601874e5aa64c5db19746770212d4b44

but without that patch this test is failing.  Remove the test for now
till the issue with the original patch can be sorted out.

Added: 


Modified: 


Removed: 
lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test



diff  --git 
a/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test 
b/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test
deleted file mode 100644
index d253981b498c8..0
--- a/lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test
+++ /dev/null
@@ -1,36 +0,0 @@
-# Test definition DIE searching is delayed until complete type is required.
-
-# UNSUPPORTED: system-windows
-
-# RUN: split-file %s %t
-# RUN: %clangxx_host %t/main.cpp %t/t1_def.cpp -gdwarf -o %t.out
-# RUN: %lldb -b %t.out -s %t/lldb.cmd | FileCheck %s
-
-# CHECK: (lldb) p v1
-# CHECK: DWARFASTParserClang::ParseTypeFromDWARF{{.*}}DW_TAG_structure_type 
(DW_TAG_structure_type) name = 't2'
-# CHECK: DWARFASTParserClang::ParseTypeFromDWARF{{.*}}DW_TAG_structure_type 
(DW_TAG_structure_type) name = 't1'
-# CHECK: DW_TAG_structure_type (DW_TAG_structure_type) 't2' resolving 
forward declaration...
-# CHECK: (t2)  {}
-# CHECK: (lldb) p v2
-# CHECK: DWARFASTParserClang::ParseTypeFromDWARF{{.*}}DW_TAG_structure_type 
(DW_TAG_structure_type) name = 't1'
-# CHECK: DW_TAG_structure_type (DW_TAG_structure_type) 't1' resolving forward 
declaration...
-
-#--- lldb.cmd
-log enable dwarf comp
-p v1
-p v2
-
-#--- main.cpp
-template
-struct t2 {
-};
-struct t1;
-t2 v1; // this CU doesn't have definition DIE for t1, but only declaration 
DIE for it.
-int main() {
-}
-
-#--- t1_def.cpp
-struct t1 { // this CU contains definition DIE for t1.
-  int x;
-};
-t1 v2;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 70de9b2 - Revert "[lldb][DWARF] Do not complete type from declaration die. (#91799)"

2024-05-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-05-13T17:47:49-07:00
New Revision: 70de9b21cbdeb1297108c4ee520b8f6dbd6496a7

URL: 
https://github.com/llvm/llvm-project/commit/70de9b21cbdeb1297108c4ee520b8f6dbd6496a7
DIFF: 
https://github.com/llvm/llvm-project/commit/70de9b21cbdeb1297108c4ee520b8f6dbd6496a7.diff

LOG: Revert "[lldb][DWARF] Do not complete type from declaration die. (#91799)"

This reverts commit a7eff59f78f08f8ef0487dfe2a136fb311af4fd0.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 034817c3b4fa1..f8101aba5c627 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -2306,11 +2306,6 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const 
DWARFDIE ,
 
   if (!die)
 return false;
-  ParsedDWARFTypeAttributes attrs(die);
-  bool is_forward_declaration = IsForwardDeclaration(
-  die, attrs, SymbolFileDWARF::GetLanguage(*die.GetCU()));
-  if (is_forward_declaration)
-return false;
 
   const dw_tag_t tag = die.Tag();
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 37b8e5f - Revert "[lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (#90663)"

2024-05-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-05-13T17:47:49-07:00
New Revision: 37b8e5feb1d065a7c474e6595bac6d2f65faeb51

URL: 
https://github.com/llvm/llvm-project/commit/37b8e5feb1d065a7c474e6595bac6d2f65faeb51
DIFF: 
https://github.com/llvm/llvm-project/commit/37b8e5feb1d065a7c474e6595bac6d2f65faeb51.diff

LOG: Revert "[lldb][DWARF] Delay struct/class/union definition DIE searching 
when parsing declaration DIEs. (#90663)"

This reverts commit 9a7262c2601874e5aa64c5db19746770212d4b44.

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.cpp
lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.h

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
index e144cf0f9bd94..66db396279e06 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
@@ -60,8 +60,6 @@ class DWARFASTParser {
 
   virtual ConstString GetDIEClassTemplateParams(const DWARFDIE ) = 0;
 
-  virtual lldb_private::Type *FindDefinitionTypeForDIE(const DWARFDIE ) = 
0;
-
   static std::optional
   ParseChildArrayInfo(const DWARFDIE _die,
   const ExecutionContext *exe_ctx = nullptr);

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index 2a46be9216121..034817c3b4fa1 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -154,26 +154,6 @@ static bool TagIsRecordType(dw_tag_t tag) {
   }
 }
 
-static bool IsForwardDeclaration(const DWARFDIE ,
- const ParsedDWARFTypeAttributes ,
- LanguageType cu_language) {
-  if (attrs.is_forward_declaration)
-return true;
-
-  // Work around an issue with clang at the moment where forward
-  // declarations for objective C classes are emitted as:
-  //  DW_TAG_structure_type [2]
-  //  DW_AT_name( "ForwardObjcClass" )
-  //  DW_AT_byte_size( 0x00 )
-  //  DW_AT_decl_file( "..." )
-  //  DW_AT_decl_line( 1 )
-  //
-  // Note that there is no DW_AT_declaration and there are no children,
-  // and the byte size is zero.
-  return attrs.byte_size && *attrs.byte_size == 0 && attrs.name &&
- !die.HasChildren() && cu_language == eLanguageTypeObjC;
-}
-
 TypeSP DWARFASTParserClang::ParseTypeFromClangModule(const SymbolContext ,
  const DWARFDIE ,
  Log *log) {
@@ -269,9 +249,11 @@ static void ForcefullyCompleteType(CompilerType type) {
 /// This function serves a similar purpose as RequireCompleteType above, but it
 /// avoids completing the type if it is not immediately necessary. It only
 /// ensures we _can_ complete the type later.
-void DWARFASTParserClang::PrepareContextToReceiveMembers(
-clang::DeclContext *decl_ctx, const DWARFDIE _ctx_die,
-const DWARFDIE , const char *type_name_cstr) {
+static void PrepareContextToReceiveMembers(TypeSystemClang ,
+   ClangASTImporter _importer,
+   clang::DeclContext *decl_ctx,
+   DWARFDIE die,
+   const char *type_name_cstr) {
   auto *tag_decl_ctx = clang::dyn_cast(decl_ctx);
   if (!tag_decl_ctx)
 return; // Non-tag context are always ready.
@@ -286,8 +268,7 @@ void DWARFASTParserClang::PrepareContextToReceiveMembers(
   // gmodules case), we can complete the type by doing a full import.
 
   // If this type was not imported from an external AST, there's nothing to do.
-  CompilerType type = m_ast.GetTypeForDecl(tag_decl_ctx);
-  ClangASTImporter _importer = GetClangASTImporter();
+  CompilerType type = ast.GetTypeForDecl(tag_decl_ctx);
   if (type && ast_importer.CanImport(type)) {
 auto qual_type = ClangUtil::GetQualType(type);
 if (ast_importer.RequireCompleteType(qual_type))
@@ -298,13 +279,6 @@ void DWARFASTParserClang::PrepareContextToReceiveMembers(
 type_name_cstr ? type_name_cstr : "", die.GetOffset());
   }
 
-  // By searching for the definition DIE of the decl_ctx type, we will either:
-  // 1. Found the the definition DIE and start its definition with
-  // TypeSystemClang::StartTagDeclarationDefinition.
-  // 2. Unable to find it, then need to forcefully complete it.
-  FindDefinitionTypeForDIE(decl_ctx_die);
-  if 

[Lldb-commits] [lldb] 22d2f3a - Move the parsed_cmd conversion def's to module level functions.

2024-02-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-02-13T18:08:02-08:00
New Revision: 22d2f3aa3097feb9a91c6d7b8ef611a1cde6d0d5

URL: 
https://github.com/llvm/llvm-project/commit/22d2f3aa3097feb9a91c6d7b8ef611a1cde6d0d5
DIFF: 
https://github.com/llvm/llvm-project/commit/22d2f3aa3097feb9a91c6d7b8ef611a1cde6d0d5.diff

LOG: Move the parsed_cmd conversion def's to module level functions.

Python3.9 does not allow you to put a reference to a class staticmethod
in a table and call it from there.  Python3.10 and following do allow
this, but we still support 3.9.  staticmethod was slightly cleaner,
but this will do.

Added: 


Modified: 
lldb/examples/python/templates/parsed_cmd.py
lldb/test/API/commands/command/script/add/TestAddParsedCommand.py

Removed: 




diff  --git a/lldb/examples/python/templates/parsed_cmd.py 
b/lldb/examples/python/templates/parsed_cmd.py
index 61ea57c275aae4..06124adf43420a 100644
--- a/lldb/examples/python/templates/parsed_cmd.py
+++ b/lldb/examples/python/templates/parsed_cmd.py
@@ -52,6 +52,65 @@ def __call__(self, debugger, args_list, exe_ctx, result):
 import sys
 from abc import abstractmethod
 
+# Some methods to translate common value types.  Should return a
+# tuple of the value and an error value (True => error) if the
+# type can't be converted.  These are called internally when the
+# command line is parsed into the 'dest' properties, you should
+# not need to call them directly.
+# FIXME: Need a way to push the conversion error string back to lldb.
+def to_bool(in_value):
+error = True
+value = False
+if type(in_value) != str or len(in_value) == 0:
+return (value, error)
+
+low_in = in_value.lower()
+if low_in in ["y", "yes", "t", "true", "1"]:
+value = True
+error = False
+
+if not value and low_in in ["n", "no", "f", "false", "0"]:
+value = False
+error = False
+
+return (value, error)
+
+def to_int(in_value):
+#FIXME: Not doing errors yet...
+return (int(in_value), False)
+
+def to_unsigned(in_value):
+# FIXME: find an unsigned converter...
+# And handle errors.
+return (int(in_value), False)
+
+translators = {
+lldb.eArgTypeBoolean : to_bool,
+lldb.eArgTypeBreakpointID : to_unsigned,
+lldb.eArgTypeByteSize : to_unsigned,
+lldb.eArgTypeCount : to_unsigned,
+lldb.eArgTypeFrameIndex : to_unsigned,
+lldb.eArgTypeIndex : to_unsigned,
+lldb.eArgTypeLineNum : to_unsigned,
+lldb.eArgTypeNumLines : to_unsigned,
+lldb.eArgTypeNumberPerLine : to_unsigned,
+lldb.eArgTypeOffset : to_int,
+lldb.eArgTypeThreadIndex : to_unsigned,
+lldb.eArgTypeUnsignedInteger : to_unsigned,
+lldb.eArgTypeWatchpointID : to_unsigned,
+lldb.eArgTypeColumnNum : to_unsigned,
+lldb.eArgTypeRecognizerID : to_unsigned,
+lldb.eArgTypeTargetID : to_unsigned,
+lldb.eArgTypeStopHookID : to_unsigned
+}
+
+def translate_value(value_type, value):
+try:
+return translators[value_type](value)
+except KeyError:
+# If we don't have a translator, return the string value.
+return (value, False)
+
 class LLDBOptionValueParser:
 """
 This class holds the option definitions for the command, and when
@@ -63,68 +122,6 @@ def __init__(self):
 self.options_dict = {}
 self.args_array = []
 
-# Some methods to translate common value types.  Should return a
-# tuple of the value and an error value (True => error) if the
-# type can't be converted.  These are called internally when the
-# command line is parsed into the 'dest' properties, you should
-# not need to call them directly.
-# FIXME: Need a way to push the conversion error string back to lldb.
-@staticmethod
-def to_bool(in_value):
-error = True
-value = False
-if type(in_value) != str or len(in_value) == 0:
-return (value, error)
-
-low_in = in_value.lower()
-if low_in in ["y", "yes", "t", "true", "1"]:
-value = True
-error = False
-
-if not value and low_in in ["n", "no", "f", "false", "0"]:
-value = False
-error = False
-
-return (value, error)
-
-@staticmethod
-def to_int(in_value):
-#FIXME: Not doing errors yet...
-return (int(in_value), False)
-
-@staticmethod
-def to_unsigned(in_value):
-# FIXME: find an unsigned converter...
-# And handle errors.
-return (int(in_value), False)
-
-translators = {
-lldb.eArgTypeBoolean : to_bool,
-lldb.eArgTypeBreakpointID : to_unsigned,
-lldb.eArgTypeByteSize : to_unsigned,
-lldb.eArgTypeCount : to_unsigned,
-lldb.eArgTypeFrameIndex : to_unsigned,
-lldb.eArgTypeIndex : to_unsigned,
-lldb.eArgTypeLineNum : to_unsigned,
-lldb.eArgTypeNumLines : to_unsigned,
-   

[Lldb-commits] [lldb] 1ec8197 - Temporarily skip this test for Python 3.9.

2024-02-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-02-13T16:51:55-08:00
New Revision: 1ec81976e4937ea9a09cefd41f25b3c5d1394f2c

URL: 
https://github.com/llvm/llvm-project/commit/1ec81976e4937ea9a09cefd41f25b3c5d1394f2c
DIFF: 
https://github.com/llvm/llvm-project/commit/1ec81976e4937ea9a09cefd41f25b3c5d1394f2c.diff

LOG: Temporarily skip this test for Python 3.9.

When the parsed command python code is run on 3.9, I get:

File ".../lib/python3.9/site-packages/lldb/plugins/parsed_cmd.py", line 124, in 
translate_value
return cls.translators[value_type](value)
TypeError: 'staticmethod' object is not callable

But this works correctly in Python 3.10 on macOS and Linux.  I'm guessing 
something
changed between those versions, and I'll have to do something to work around 
the difference.
But I'm going to skip the test on 3.9 while I figure that out.

Added: 


Modified: 
lldb/test/API/commands/command/script/add/TestAddParsedCommand.py

Removed: 




diff  --git a/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py 
b/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
index bbf330500568b5..6cbe888af99dc6 100644
--- a/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
+++ b/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
@@ -15,6 +15,7 @@ class ParsedCommandTestCase(TestBase):
 
 # This crashes on the x86_64 Debian bot, but the failure is not helpful.
 # Disable the test while I try to find a way to reproduce.
+@skipIf(py_version=("<=", (3, 9)))
 def test(self):
 self.pycmd_tests()
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 3647ff1 - Used std::vector::reserve when I meant std::vector::resize.

2024-02-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-02-13T16:12:20-08:00
New Revision: 3647ff159a2f2445c45d9cbb4f8791b5f30da16b

URL: 
https://github.com/llvm/llvm-project/commit/3647ff159a2f2445c45d9cbb4f8791b5f30da16b
DIFF: 
https://github.com/llvm/llvm-project/commit/3647ff159a2f2445c45d9cbb4f8791b5f30da16b.diff

LOG: Used std::vector::reserve when I meant std::vector::resize.

The Linux std has more asserts enabled by default, so it
complained, even though this worked on Darwin...

Added: 


Modified: 
lldb/source/Commands/CommandObjectCommands.cpp
lldb/test/API/commands/command/script/add/TestAddParsedCommand.py

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index 3dfd452b92509d..b7cd65059b2214 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -1419,9 +1419,9 @@ class CommandObjectScriptingObjectParsed : public 
CommandObjectParsed {
   m_options_definition_up.reset(new OptionDefinition[m_num_options]);
   // We need to hand out pointers to contents of these vectors; we reserve
   // as much as we'll need up front so they don't get freed on resize...
-  m_usage_container.reserve(m_num_options);
-  m_enum_storage.reserve(m_num_options);
-  m_enum_vector.reserve(m_num_options);
+  m_usage_container.resize(m_num_options);
+  m_enum_storage.resize(m_num_options);
+  m_enum_vector.resize(m_num_options);
   
   size_t counter = 0;
   size_t short_opt_counter = 0;

diff  --git a/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py 
b/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
index c044e2bf8c8d28..bbf330500568b5 100644
--- a/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
+++ b/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
@@ -15,7 +15,6 @@ class ParsedCommandTestCase(TestBase):
 
 # This crashes on the x86_64 Debian bot, but the failure is not helpful.
 # Disable the test while I try to find a way to reproduce.
-@skipIfLinux 
 def test(self):
 self.pycmd_tests()
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] f0b271e - Temporarily disable the TestAddParsedCommand.py while I figure out

2024-02-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2024-02-13T13:16:30-08:00
New Revision: f0b271e4ebd2180f497694838ec9db0b2fd8ab4b

URL: 
https://github.com/llvm/llvm-project/commit/f0b271e4ebd2180f497694838ec9db0b2fd8ab4b
DIFF: 
https://github.com/llvm/llvm-project/commit/f0b271e4ebd2180f497694838ec9db0b2fd8ab4b.diff

LOG: Temporarily disable the TestAddParsedCommand.py while I figure out
why it's crashing on the x86_64 Debian Linux worker.

Added: 


Modified: 
lldb/test/API/commands/command/script/add/TestAddParsedCommand.py

Removed: 




diff  --git a/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py 
b/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
index 7dba9c6937f211..c044e2bf8c8d28 100644
--- a/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
+++ b/lldb/test/API/commands/command/script/add/TestAddParsedCommand.py
@@ -13,6 +13,9 @@
 class ParsedCommandTestCase(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
+# This crashes on the x86_64 Debian bot, but the failure is not helpful.
+# Disable the test while I try to find a way to reproduce.
+@skipIfLinux 
 def test(self):
 self.pycmd_tests()
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 0f339e6 - Fix a bug in handling ^C at the "y/n/a" completion prompt.

2023-09-27 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-09-27T17:20:48-07:00
New Revision: 0f339e6567bffb290e409ef5de272fb75ce70234

URL: 
https://github.com/llvm/llvm-project/commit/0f339e6567bffb290e409ef5de272fb75ce70234
DIFF: 
https://github.com/llvm/llvm-project/commit/0f339e6567bffb290e409ef5de272fb75ce70234.diff

LOG: Fix a bug in handling ^C at the "y/n/a" completion prompt.

We just forget to check for interrupt while waiting for the answer to the 
prompt. But if we are in the interrupt state then the lower
layers of the EditLine code just eat all characters so we never get out of the 
query prompt. You're pretty much stuck and have to kill lldb.

The solution is to check for the interrupt. The patch is a little bigger 
because where I needed to check the Interrupt state I only
had the ::EditLine object, but the editor state is held in lldb's EditLine 
wrapper, so I had to do a little work to get my hands on it.

Added: 


Modified: 
lldb/include/lldb/Host/Editline.h
lldb/source/Host/common/Editline.cpp
lldb/test/API/iohandler/completion/TestIOHandlerCompletion.py

Removed: 




diff  --git a/lldb/include/lldb/Host/Editline.h 
b/lldb/include/lldb/Host/Editline.h
index e1807aa5492680e..c598244150788da 100644
--- a/lldb/include/lldb/Host/Editline.h
+++ b/lldb/include/lldb/Host/Editline.h
@@ -161,6 +161,10 @@ class Editline {
   /// of Editline.
   static Editline *InstanceFor(::EditLine *editline);
 
+  static void
+  DisplayCompletions(Editline ,
+ llvm::ArrayRef results);
+
   /// Sets a string to be used as a prompt, or combined with a line number to
   /// form a prompt.
   void SetPrompt(const char *prompt);

diff  --git a/lldb/source/Host/common/Editline.cpp 
b/lldb/source/Host/common/Editline.cpp
index edefbf4008129e4..82e17ec753ab235 100644
--- a/lldb/source/Host/common/Editline.cpp
+++ b/lldb/source/Host/common/Editline.cpp
@@ -943,12 +943,12 @@ PrintCompletion(FILE *output_file,
   }
 }
 
-static void
-DisplayCompletions(::EditLine *editline, FILE *output_file,
-   llvm::ArrayRef results) {
+void Editline::DisplayCompletions(
+Editline , llvm::ArrayRef results) {
   assert(!results.empty());
 
-  fprintf(output_file, "\n" ANSI_CLEAR_BELOW "Available completions:\n");
+  fprintf(editline.m_output_file,
+  "\n" ANSI_CLEAR_BELOW "Available completions:\n");
   const size_t page_size = 40;
   bool all = false;
 
@@ -960,7 +960,7 @@ DisplayCompletions(::EditLine *editline, FILE *output_file,
   const size_t max_len = longest->GetCompletion().size();
 
   if (results.size() < page_size) {
-PrintCompletion(output_file, results, max_len);
+PrintCompletion(editline.m_output_file, results, max_len);
 return;
   }
 
@@ -969,17 +969,25 @@ DisplayCompletions(::EditLine *editline, FILE 
*output_file,
 size_t remaining = results.size() - cur_pos;
 size_t next_size = all ? remaining : std::min(page_size, remaining);
 
-PrintCompletion(output_file, results.slice(cur_pos, next_size), max_len);
+PrintCompletion(editline.m_output_file, results.slice(cur_pos, next_size),
+max_len);
 
 cur_pos += next_size;
 
 if (cur_pos >= results.size())
   break;
 
-fprintf(output_file, "More (Y/n/a): ");
+fprintf(editline.m_output_file, "More (Y/n/a): ");
 char reply = 'n';
-int got_char = el_getc(editline, );
-fprintf(output_file, "\n");
+int got_char = el_getc(editline.m_editline, );
+// Check for a ^C or other interruption.
+if (editline.m_editor_status == EditorStatus::Interrupted) {
+  editline.m_editor_status = EditorStatus::Editing;
+  fprintf(editline.m_output_file, "^C\n");
+  break;
+}
+
+fprintf(editline.m_output_file, "\n");
 if (got_char == -1 || reply == 'n')
   break;
 if (reply == 'a')
@@ -1050,7 +1058,7 @@ unsigned char Editline::TabCommand(int ch) {
 return CC_REDISPLAY;
   }
 
-  DisplayCompletions(m_editline, m_output_file, results);
+  DisplayCompletions(*this, results);
 
   DisplayInput();
   MoveCursor(CursorLocation::BlockEnd, CursorLocation::EditingCursor);

diff  --git a/lldb/test/API/iohandler/completion/TestIOHandlerCompletion.py 
b/lldb/test/API/iohandler/completion/TestIOHandlerCompletion.py
index 0e28a94adf1e4a3..b16869b05e7df0e 100644
--- a/lldb/test/API/iohandler/completion/TestIOHandlerCompletion.py
+++ b/lldb/test/API/iohandler/completion/TestIOHandlerCompletion.py
@@ -75,6 +75,12 @@ def test_completion(self):
 self.child.send("n")
 self.expect_prompt()
 
+# Start tab completion and abort showing more commands with '^C'.
+self.child.send("\t")
+self.child.expect_exact("More (Y/n/a)")
+self.child.sendcontrol("c")
+self.expect_prompt()
+
 # Shouldn't crash or anything like that.
 self.child.send("regoinvalid\t")
 self.expect_prompt()




[Lldb-commits] [lldb] b9e08cb - I can't make this test fail locally, but it is failing on the macOS

2023-09-21 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-09-21T13:30:45-07:00
New Revision: b9e08cbf3037e03bdb2da700db3b02ed32e49b78

URL: 
https://github.com/llvm/llvm-project/commit/b9e08cbf3037e03bdb2da700db3b02ed32e49b78
DIFF: 
https://github.com/llvm/llvm-project/commit/b9e08cbf3037e03bdb2da700db3b02ed32e49b78.diff

LOG: I can't make this test fail locally, but it is failing on the macOS
bots as well.  I'll have to figure out a different way to test this.

Added: 


Modified: 
lldb/test/API/commands/process/attach/TestProcessAttach.py

Removed: 




diff  --git a/lldb/test/API/commands/process/attach/TestProcessAttach.py 
b/lldb/test/API/commands/process/attach/TestProcessAttach.py
index d821b4128cde019..7be36f9644a4fa5 100644
--- a/lldb/test/API/commands/process/attach/TestProcessAttach.py
+++ b/lldb/test/API/commands/process/attach/TestProcessAttach.py
@@ -129,87 +129,3 @@ def tearDown(self):
 # Call super's tearDown().
 TestBase.tearDown(self)
 
-# This test is flakey on Linux & Windows.  The failure mode is
-# that sometimes we miss the interrupt and never succeed in
-# getting out of the attach wait.
-@skipUnlessDarwin
-def test_run_then_attach_wait_interrupt(self):
-# Test that having run one process doesn't cause us to be unable
-# to interrupt a subsequent attach attempt.
-self.build()
-exe = self.getBuildArtifact(exe_name)
-
-target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
-launch_info = target.GetLaunchInfo()
-launch_info.SetArguments(["q"], True)
-error = lldb.SBError()
-target.Launch(launch_info, error)
-self.assertSuccess(error, "Launched a process")
-self.assertState(target.process.state, lldb.eStateExited, "and it 
exited.") 
-
-# Okay now we've run a process, try to attach/wait to something
-# and make sure that we can interrupt that.
-
-options = lldb.SBCommandInterpreterRunOptions()
-options.SetPrintResults(True)
-options.SetEchoCommands(False)
-
-self.stdin_path = self.getBuildArtifact("stdin.txt")
-
-with open(self.stdin_path, "w") as input_handle:
-input_handle.write("process attach -w -n 
noone_would_use_this_name\nquit")
-
-# Python will close the file descriptor if all references
-# to the filehandle object lapse, so we need to keep one
-# around.
-self.filehandle = open(self.stdin_path, "r")
-self.dbg.SetInputFileHandle(self.filehandle, False)
-
-# No need to track the output
-self.stdout_path = self.getBuildArtifact("stdout.txt")
-self.out_filehandle = open(self.stdout_path, "w")
-self.dbg.SetOutputFileHandle(self.out_filehandle, False)
-self.dbg.SetErrorFileHandle(self.out_filehandle, False)
-
-n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
-True, True, options, 0, False, False)
-
-while 1:
-time.sleep(1)
-if target.process.state == lldb.eStateAttaching:
-break
-
-self.dbg.DispatchInputInterrupt()
-self.dbg.DispatchInputInterrupt()
-
-# cycle waiting for the process state to change before trying
-# to read the command output.  I don't want to spin forever.
-counter = 0
-got_exit = False
-while counter < 20:
-if target.process.state == lldb.eStateExited:
-got_exit = True
-break
-counter += 1
-time.sleep(1)
-
-self.assertTrue(got_exit, "The process never switched to eStateExited")
-# Even if the state has flipped, we still need to wait for the
-# command to complete to see the result.  We don't have a way to
-# synchronize on "command completed" right now, but sleeping just
-# a bit should be enough, all that's left is passing this error
-# result to the command, and printing it to the debugger output.
-time.sleep(1)
-
-self.out_filehandle.flush()
-reader = open(self.stdout_path, "r")
-results = reader.readlines()
-found_result = False
-for line in results:
-if "Cancelled async attach" in line:
-found_result = True
-break
-if not found_result:
-print(f"Results: {results}")
-
-self.assertTrue(found_result, "Found async error in results")



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 3c61e4b - Copy and paste error in a file header.

2023-09-20 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-09-20T17:43:44-07:00
New Revision: 3c61e4bf28538f5f267b073634e394dd5000af85

URL: 
https://github.com/llvm/llvm-project/commit/3c61e4bf28538f5f267b073634e394dd5000af85
DIFF: 
https://github.com/llvm/llvm-project/commit/3c61e4bf28538f5f267b073634e394dd5000af85.diff

LOG: Copy and paste error in a file header.

Added: 


Modified: 
lldb/source/Symbol/SymbolFileOnDemand.cpp

Removed: 




diff  --git a/lldb/source/Symbol/SymbolFileOnDemand.cpp 
b/lldb/source/Symbol/SymbolFileOnDemand.cpp
index d3694580194f34c..19b519c63a8a0b7 100644
--- a/lldb/source/Symbol/SymbolFileOnDemand.cpp
+++ b/lldb/source/Symbol/SymbolFileOnDemand.cpp
@@ -1,4 +1,4 @@
-//===-- SymbolFileDWARFDebugMap.cpp 
---===//
+//===-- SymbolFileOnDemand.cpp ---===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] de94c10 - The test: test_run_then_attach_wait_interrupt was flakey on Linux & Windows.

2023-09-20 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-09-20T17:38:27-07:00
New Revision: de94c109b64d098c52ffc6f60daadb3eaa8fb944

URL: 
https://github.com/llvm/llvm-project/commit/de94c109b64d098c52ffc6f60daadb3eaa8fb944
DIFF: 
https://github.com/llvm/llvm-project/commit/de94c109b64d098c52ffc6f60daadb3eaa8fb944.diff

LOG: The test: test_run_then_attach_wait_interrupt was flakey on Linux & 
Windows.

I changed the test so I could tell whether the problem was sometimes the
interrupt was failing, or maybe the was just racy.  It failed again, but
in the new failures we waited 20 seconds for the attach-wait to get interrupted
and that never happened.

So there seems to be some real raciness in the feature of interrupting an
attach-wait, but only on Linux & Windows.  The bug fix that this test was
testing was for a bug that would cause us to never try to interrupt in this
case.  So it looks like this test is uncovering some flakiness in the underlying
interrupt support when in this state.  That's a separate bug that needs fixing.

For now, I disabled the test except on macOS where it seems to run reliably.

Added: 


Modified: 
lldb/test/API/commands/process/attach/TestProcessAttach.py

Removed: 




diff  --git a/lldb/test/API/commands/process/attach/TestProcessAttach.py 
b/lldb/test/API/commands/process/attach/TestProcessAttach.py
index 0e916d2e8e4cbe1..d821b4128cde019 100644
--- a/lldb/test/API/commands/process/attach/TestProcessAttach.py
+++ b/lldb/test/API/commands/process/attach/TestProcessAttach.py
@@ -128,3 +128,88 @@ def tearDown(self):
 
 # Call super's tearDown().
 TestBase.tearDown(self)
+
+# This test is flakey on Linux & Windows.  The failure mode is
+# that sometimes we miss the interrupt and never succeed in
+# getting out of the attach wait.
+@skipUnlessDarwin
+def test_run_then_attach_wait_interrupt(self):
+# Test that having run one process doesn't cause us to be unable
+# to interrupt a subsequent attach attempt.
+self.build()
+exe = self.getBuildArtifact(exe_name)
+
+target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
+launch_info = target.GetLaunchInfo()
+launch_info.SetArguments(["q"], True)
+error = lldb.SBError()
+target.Launch(launch_info, error)
+self.assertSuccess(error, "Launched a process")
+self.assertState(target.process.state, lldb.eStateExited, "and it 
exited.") 
+
+# Okay now we've run a process, try to attach/wait to something
+# and make sure that we can interrupt that.
+
+options = lldb.SBCommandInterpreterRunOptions()
+options.SetPrintResults(True)
+options.SetEchoCommands(False)
+
+self.stdin_path = self.getBuildArtifact("stdin.txt")
+
+with open(self.stdin_path, "w") as input_handle:
+input_handle.write("process attach -w -n 
noone_would_use_this_name\nquit")
+
+# Python will close the file descriptor if all references
+# to the filehandle object lapse, so we need to keep one
+# around.
+self.filehandle = open(self.stdin_path, "r")
+self.dbg.SetInputFileHandle(self.filehandle, False)
+
+# No need to track the output
+self.stdout_path = self.getBuildArtifact("stdout.txt")
+self.out_filehandle = open(self.stdout_path, "w")
+self.dbg.SetOutputFileHandle(self.out_filehandle, False)
+self.dbg.SetErrorFileHandle(self.out_filehandle, False)
+
+n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
+True, True, options, 0, False, False)
+
+while 1:
+time.sleep(1)
+if target.process.state == lldb.eStateAttaching:
+break
+
+self.dbg.DispatchInputInterrupt()
+self.dbg.DispatchInputInterrupt()
+
+# cycle waiting for the process state to change before trying
+# to read the command output.  I don't want to spin forever.
+counter = 0
+got_exit = False
+while counter < 20:
+if target.process.state == lldb.eStateExited:
+got_exit = True
+break
+counter += 1
+time.sleep(1)
+
+self.assertTrue(got_exit, "The process never switched to eStateExited")
+# Even if the state has flipped, we still need to wait for the
+# command to complete to see the result.  We don't have a way to
+# synchronize on "command completed" right now, but sleeping just
+# a bit should be enough, all that's left is passing this error
+# result to the command, and printing it to the debugger output.
+time.sleep(1)
+
+self.out_filehandle.flush()
+reader = open(self.stdout_path, "r")
+results = reader.readlines()
+found_result = False
+for line in 

[Lldb-commits] [lldb] df93c4f - Remove some raciness from the TestProcessAttach.test_run_then_attach_wait_interrupt

2023-09-20 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-09-20T13:08:40-07:00
New Revision: df93c4ffdf220630ecceba5c9a7822c0aca7deaa

URL: 
https://github.com/llvm/llvm-project/commit/df93c4ffdf220630ecceba5c9a7822c0aca7deaa
DIFF: 
https://github.com/llvm/llvm-project/commit/df93c4ffdf220630ecceba5c9a7822c0aca7deaa.diff

LOG: Remove some raciness from the 
TestProcessAttach.test_run_then_attach_wait_interrupt
command.

We were reading the command output right after sending the interrupt, but
sometimes that wasn't long enough for the command result text to have been 
emitted.
I added a poll for the state change to eStateExited, and then added a bit more 
sleep
to give the command a chance to complete.

Added: 


Modified: 
lldb/test/API/commands/process/attach/TestProcessAttach.py

Removed: 




diff  --git a/lldb/test/API/commands/process/attach/TestProcessAttach.py 
b/lldb/test/API/commands/process/attach/TestProcessAttach.py
index 0e916d2e8e4cbe1..1f5359977480be6 100644
--- a/lldb/test/API/commands/process/attach/TestProcessAttach.py
+++ b/lldb/test/API/commands/process/attach/TestProcessAttach.py
@@ -4,6 +4,8 @@
 
 
 import os
+import threading
+import time
 import lldb
 import shutil
 from lldbsuite.test.decorators import *
@@ -128,3 +130,84 @@ def tearDown(self):
 
 # Call super's tearDown().
 TestBase.tearDown(self)
+
+def test_run_then_attach_wait_interrupt(self):
+# Test that having run one process doesn't cause us to be unable
+# to interrupt a subsequent attach attempt.
+self.build()
+exe = self.getBuildArtifact(exe_name)
+
+target = lldbutil.run_to_breakpoint_make_target(self, exe_name, True)
+launch_info = target.GetLaunchInfo()
+launch_info.SetArguments(["q"], True)
+error = lldb.SBError()
+target.Launch(launch_info, error)
+self.assertSuccess(error, "Launched a process")
+self.assertState(target.process.state, lldb.eStateExited, "and it 
exited.") 
+
+# Okay now we've run a process, try to attach/wait to something
+# and make sure that we can interrupt that.
+
+options = lldb.SBCommandInterpreterRunOptions()
+options.SetPrintResults(True)
+options.SetEchoCommands(False)
+
+self.stdin_path = self.getBuildArtifact("stdin.txt")
+
+with open(self.stdin_path, "w") as input_handle:
+input_handle.write("process attach -w -n 
noone_would_use_this_name\nquit")
+
+# Python will close the file descriptor if all references
+# to the filehandle object lapse, so we need to keep one
+# around.
+self.filehandle = open(self.stdin_path, "r")
+self.dbg.SetInputFileHandle(self.filehandle, False)
+
+# No need to track the output
+self.stdout_path = self.getBuildArtifact("stdout.txt")
+self.out_filehandle = open(self.stdout_path, "w")
+self.dbg.SetOutputFileHandle(self.out_filehandle, False)
+self.dbg.SetErrorFileHandle(self.out_filehandle, False)
+
+n_errors, quit_req, crashed = self.dbg.RunCommandInterpreter(
+True, True, options, 0, False, False)
+
+while 1:
+time.sleep(1)
+if target.process.state == lldb.eStateAttaching:
+break
+
+self.dbg.DispatchInputInterrupt()
+self.dbg.DispatchInputInterrupt()
+
+# cycle waiting for the process state to change before trying
+# to read the command output.  I don't want to spin forever.
+counter = 0
+got_exit = False
+while counter < 20:
+if target.process.state == lldb.eStateExited:
+got_exit = True
+break
+counter += 1
+time.sleep(1)
+
+self.assertTrue(got_exit, "The process never switched to eStateExited")
+# Even if the state has flipped, we still need to wait for the
+# command to complete to see the result.  We don't have a way to
+# synchronize on "command completed" right now, but sleeping just
+# a bit should be enough, all that's left is passing this error
+# result to the command, and printing it to the debugger output.
+time.sleep(1)
+
+self.out_filehandle.flush()
+reader = open(self.stdout_path, "r")
+results = reader.readlines()
+found_result = False
+for line in results:
+if "Cancelled async attach" in line:
+found_result = True
+break
+if not found_result:
+print(f"Results: {results}")
+
+self.assertTrue(found_result, "Found async error in results")



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 74338bf - A test was changing directory and then incorrectly restoring the directory

2023-09-19 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-09-19T16:46:08-07:00
New Revision: 74338bfe0cfec8b8db24af131cdeb664e346a1b5

URL: 
https://github.com/llvm/llvm-project/commit/74338bfe0cfec8b8db24af131cdeb664e346a1b5
DIFF: 
https://github.com/llvm/llvm-project/commit/74338bfe0cfec8b8db24af131cdeb664e346a1b5.diff

LOG: A test was changing directory and then incorrectly restoring the directory
to the "testdir" which is the build directory for that test, not the
original source directory.  That caused subsequent tests to fail.

Added: 


Modified: 
lldb/test/API/commands/process/attach/TestProcessAttach.py

Removed: 




diff  --git a/lldb/test/API/commands/process/attach/TestProcessAttach.py 
b/lldb/test/API/commands/process/attach/TestProcessAttach.py
index 67bb134ec0148a0..99ff3a4ec4db816 100644
--- a/lldb/test/API/commands/process/attach/TestProcessAttach.py
+++ b/lldb/test/API/commands/process/attach/TestProcessAttach.py
@@ -74,7 +74,8 @@ def test_attach_to_process_from_
diff erent_dir_by_id(self):
 popen = self.spawnSubprocess(exe)
 
 os.chdir(newdir)
-self.addTearDownHook(lambda: os.chdir(testdir))
+sourcedir = self.getSourceDir()
+self.addTearDownHook(lambda: os.chdir(sourcedir))
 self.runCmd("process attach -p " + str(popen.pid))
 
 target = self.dbg.GetSelectedTarget()



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [lldb] [lldb] Add a setting to customize the prompt color (PR #66218)

2023-09-13 Thread Jim Ingham via lldb-commits
We actually have several requests for this internally, and I think that's a 
good idea.  

However, some of the format tokens can return arbitrary text, including 
newlines, for instance "thread.completed-expression", and all the "script." 
ones.  Do we want to try to support prompts with new-lines or do we want to 
restrict the format string for prompts or somehow cut off these arbitrary 
elements at the first new-line?

Jim

> On Sep 13, 2023, at 9:53 AM, Greg Clayton via lldb-commits 
>  wrote:
> 
> 
> https://github.com/clayborg commented:
> 
> Any interest in just allowing "settings set prompt" to use the format strings 
> approach that we support in thread-format, frame-format? I see we have a ton 
> of settings that already ansi-prefix and ansi-suffix settings, but it would 
> be easy to just do:
> ```
> (lldb) setting set prompt "${ansi.fg.red}(lldb) ${ansi.normal}"
> ```
> It we didn't just expand the above string one time, we could be able to make 
> some really powerful LLDB prompts if we used the format strings:
> ```
> (lldb) setting set prompt "{pid = ${process.id} }{tid = ${thread.id%tid}} 
> ${ansi.fg.red}(lldb) ${ansi.normal}"
> ```
> Just an idea, not a requirement for this patch
> 
> https://github.com/llvm/llvm-project/pull/66218
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [lldb] Add `target modules dump separate-debug-info` (PR #66035)

2023-09-12 Thread Jim Ingham via lldb-commits
Not necessary for this review, but it might be nice to have a --missing or 
similar flag to this command that filters the output to only the ones that are 
missing.  Seems like a lot of the time I would want to use this command it 
would be to find missing dwo or oso files.

Jim


> On Sep 11, 2023, at 5:59 PM, Greg Clayton via lldb-commits 
>  wrote:
> 
> 
> clayborg wrote:
> 
> We also want to show the .dwo error or OSO error strings that explain why the 
> file wasn't loaded as we see when we do "frame variable" and the OSO or DWO 
> are missing. 
> 
> https://github.com/llvm/llvm-project/pull/66035
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [lldb] [lldb] Format Python files in scripts and utils (PR #66053)

2023-09-12 Thread Jim Ingham via lldb-commits
Is there any chance we can use something other than black.  I would never never 
write Python code that ugly.

Jim


> On Sep 12, 2023, at 8:47 AM, Adrian Prantl via lldb-commits 
>  wrote:
> 
> 
> adrian-prantl wrote:
> 
> Have (should we) we documented that we format all python code with black 
> somewhere and how to install the tool?
> 
> https://github.com/llvm/llvm-project/pull/66053
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] d268ba3 - Test follow-up to 2e7aa2ee34eb53347396731dc8a3b2dbc6a3df45

2023-08-16 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-08-16T12:19:07-07:00
New Revision: d268ba38083cd7c9c4f55cb0792d4a0db1d4768b

URL: 
https://github.com/llvm/llvm-project/commit/d268ba38083cd7c9c4f55cb0792d4a0db1d4768b
DIFF: 
https://github.com/llvm/llvm-project/commit/d268ba38083cd7c9c4f55cb0792d4a0db1d4768b.diff

LOG: Test follow-up to 2e7aa2ee34eb53347396731dc8a3b2dbc6a3df45

The TestEvents.py test I added for ShadowListeners fails on Windows.
Since there's no reason to believe the ShadowListeners feature has
different behavior from the other event-based tests here, I copied
the skips & expected_flakey's from the other tests in that file to
this one.

Added: 


Modified: 
lldb/test/API/python_api/event/TestEvents.py

Removed: 




diff  --git a/lldb/test/API/python_api/event/TestEvents.py 
b/lldb/test/API/python_api/event/TestEvents.py
index a8a67a94a84345..9c933d440847c5 100644
--- a/lldb/test/API/python_api/event/TestEvents.py
+++ b/lldb/test/API/python_api/event/TestEvents.py
@@ -347,6 +347,9 @@ def wait_for_next_event(self, expected_state, test_shadow = 
False):
 
 return state, restart
 
+@expectedFlakeyLinux("llvm.org/pr23730")  # Flaky, fails ~1/100 cases
+@skipIfWindows  # This is flakey on Windows AND when it fails, it hangs: 
llvm.org/pr38373
+@skipIfNetBSD
 def test_shadow_listener(self):
 self.build()
 exe = self.getBuildArtifact("a.out")



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 2e7aa2e - Replace the singleton "ShadowListener" with a primary and N secondary Listeners

2023-08-16 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-08-16T10:35:32-07:00
New Revision: 2e7aa2ee34eb53347396731dc8a3b2dbc6a3df45

URL: 
https://github.com/llvm/llvm-project/commit/2e7aa2ee34eb53347396731dc8a3b2dbc6a3df45
DIFF: 
https://github.com/llvm/llvm-project/commit/2e7aa2ee34eb53347396731dc8a3b2dbc6a3df45.diff

LOG: Replace the singleton "ShadowListener" with a primary and N secondary 
Listeners

Before the addition of the process "Shadow Listener" you could only have one
Listener observing the Process Broadcaster.  That was necessary because 
fetching the
Process event is what switches the public process state, and for the execution
control logic to be manageable you needed to keep other listeners from causing
this to happen before the main process control engine was ready.

Ismail added the notion of a "ShadowListener" - which allowed you ONE
extra process listener.  This patch inverts that setup by designating the
first listener as primary - and giving it priority in fetching events.

Differential Revision: https://reviews.llvm.org/D157556

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Utility/Broadcaster.h
lldb/include/lldb/Utility/Event.h
lldb/source/Target/Process.cpp
lldb/source/Utility/Broadcaster.cpp
lldb/source/Utility/Event.cpp
lldb/source/Utility/Listener.cpp
lldb/test/API/api/listeners/TestListener.py

lldb/test/API/functionalities/interactive_scripted_process/TestInteractiveScriptedProcess.py
lldb/test/API/python_api/event/TestEvents.py

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 6ea6f82548aaf8..2186eea7ef5054 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -352,6 +352,14 @@ class Process : public 
std::enable_shared_from_this,
 eBroadcastBitProfileData = (1 << 4),
 eBroadcastBitStructuredData = (1 << 5),
   };
+  // This is all the event bits the public process broadcaster broadcasts.
+  // The process shadow listener signs up for all these bits...
+  static constexpr int g_all_event_bits = eBroadcastBitStateChanged 
+| eBroadcastBitInterrupt
+| eBroadcastBitSTDOUT 
+| eBroadcastBitSTDERR
+| eBroadcastBitProfileData 
+| eBroadcastBitStructuredData;
 
   enum {
 eBroadcastInternalStateControlStop = (1 << 0),
@@ -382,11 +390,7 @@ class Process : public 
std::enable_shared_from_this,
   ConstString () const override {
 return GetStaticBroadcasterClass();
   }
-
-  void SetShadowListener(lldb::ListenerSP listener_sp) override {
-Broadcaster::SetShadowListener(listener_sp);
-  }
-
+  
 /// A notification structure that can be used by clients to listen
 /// for changes in a process's lifetime.
 ///
@@ -610,6 +614,15 @@ class Process : public 
std::enable_shared_from_this,
 return error;
   }
 
+  /// The "ShadowListener" for a process is just an ordinary Listener that 
+  /// listens for all the Process event bits.  It's convenient because you can
+  /// specify it in the LaunchInfo or AttachInfo, so it will get events from
+  /// the very start of the process.
+  void SetShadowListener(lldb::ListenerSP shadow_listener_sp) {
+if (shadow_listener_sp)
+  AddListener(shadow_listener_sp, g_all_event_bits);
+  }
+
   // FUTURE WORK: GetLoadImageUtilityFunction are the first use we've
   // had of having other plugins cache data in the Process.  This is handy for
   // long-living plugins - like the Platform - which manage interactions whose
@@ -2979,8 +2992,6 @@ void PruneThreadPlans();
   std::vector m_notifications; ///< The list of notifications
   ///that this process can deliver.
   std::vector m_image_tokens;
-  lldb::ListenerSP m_listener_sp; ///< Shared pointer to the listener used for
-  ///public events.  Can not be empty.
   BreakpointSiteList m_breakpoint_site_list; ///< This is the list of 
breakpoint
  ///locations we intend to insert 
in
  ///the target.

diff  --git a/lldb/include/lldb/Utility/Broadcaster.h 
b/lldb/include/lldb/Utility/Broadcaster.h
index f9887566a1609d..8444c38f6ecc65 100644
--- a/lldb/include/lldb/Utility/Broadcaster.h
+++ b/lldb/include/lldb/Utility/Broadcaster.h
@@ -312,8 +312,12 @@ class Broadcaster {
 
   lldb::BroadcasterManagerSP GetManager();
 
-  virtual void SetShadowListener(lldb::ListenerSP listener_sp) {
-m_broadcaster_sp->m_shadow_listener = listener_sp;
+  void SetPrimaryListener(lldb::ListenerSP listener_sp) {
+m_broadcaster_sp->SetPrimaryListener(listener_sp);
+  }
+
+  lldb::ListenerSP GetPrimaryListener() {
+  

[Lldb-commits] [lldb] 4185656 - Fix the NSIndexSet data formatter for changes in macOS Sonoma.

2023-08-04 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-08-04T09:55:59-07:00
New Revision: 4185656625a249832ff67f628bd00e5278721c96

URL: 
https://github.com/llvm/llvm-project/commit/4185656625a249832ff67f628bd00e5278721c96
DIFF: 
https://github.com/llvm/llvm-project/commit/4185656625a249832ff67f628bd00e5278721c96.diff

LOG: Fix the NSIndexSet data formatter for changes in macOS Sonoma.

Added: 


Modified: 
lldb/source/Plugins/Language/ObjC/Cocoa.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp 
b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
index 374ac763ab183d..f1a7e04bc9d1bf 100644
--- a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
+++ b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
@@ -237,7 +237,8 @@ bool lldb_private::formatters::NSIndexSetSummaryProvider(
   if (!process_sp)
 return false;
 
-  ObjCLanguageRuntime *runtime = ObjCLanguageRuntime::Get(*process_sp);
+  AppleObjCRuntime *runtime = llvm::dyn_cast_or_null(
+  ObjCLanguageRuntime::Get(*process_sp));
 
   if (!runtime)
 return false;
@@ -264,20 +265,56 @@ bool lldb_private::formatters::NSIndexSetSummaryProvider(
 
   do {
 if (class_name == "NSIndexSet" || class_name == "NSMutableIndexSet") {
+  // Foundation version 2000 added a bitmask if the index set fit in 64 
bits
+  // and a Tagged Pointer version if the bitmask is small enough to fit in
+  // the tagged pointer payload.  
+  // It also changed the layout (but not the size) of the set descriptor.
+
+  // First check whether this is a tagged pointer.  The bitmask will be in
+  // the payload of the tagged pointer.
+  uint64_t payload;
+  if (runtime->GetFoundationVersion() >= 2000  
+  && descriptor->GetTaggedPointerInfo(nullptr, nullptr, )) {
+count = llvm::popcount(payload);
+break;
+  }
+  // The first 32 bits describe the index set in all cases:
   Status error;
   uint32_t mode = process_sp->ReadUnsignedIntegerFromMemory(
-  valobj_addr + ptr_size, 4, 0, error);
+valobj_addr + ptr_size, 4, 0, error);
   if (error.Fail())
 return false;
-  // this means the set is empty - count = 0
-  if ((mode & 1) == 1) {
-count = 0;
-break;
+  // Now check if the index is held in a bitmask in the object:
+  if (runtime->GetFoundationVersion() >= 2000) {
+// The first two bits are "isSingleRange" and "isBitfield".  If this is
+// a bitfield we handle it here, otherwise set mode appropriately and
+// the rest of the treatment is in common.
+if ((mode & 2) == 2) {
+  // The bitfield is a 64 bit uint at the beginning of the data var.
+  uint64_t bitfield = process_sp->ReadUnsignedIntegerFromMemory(
+valobj_addr + 2 * ptr_size, 8, 0, error);
+  if (error.Fail())
+return false;
+  count = llvm::popcount(bitfield);
+  break;
+}
+// It wasn't a bitfield, so read the isSingleRange from its new loc:
+if ((mode & 1) == 1)
+  mode = 1; // this means the set only has one range
+else
+  mode = 2; // this means the set has multiple ranges
+  } else {
+// this means the set is empty - count = 0
+if ((mode & 1) == 1) {
+  count = 0;
+  break;
+}
+  
+if ((mode & 2) == 2)
+  mode = 1; // this means the set only has one range
+else
+  mode = 2; // this means the set has multiple ranges
   }
-  if ((mode & 2) == 2)
-mode = 1; // this means the set only has one range
-  else
-mode = 2; // this means the set has multiple ranges
   if (mode == 1) {
 count = process_sp->ReadUnsignedIntegerFromMemory(
 valobj_addr + 3 * ptr_size, ptr_size, 0, error);



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D149213: [lldb] Add basic support for Rust enums in TypeSystemClang

2023-07-21 Thread Jim Ingham via lldb-commits


> On Jul 21, 2023, at 9:52 AM, J. Ryan Stinnett via Phabricator via 
> lldb-commits  wrote:
> 
> jryans added a comment.
> 
> In D149213#4491889 , 
> @VladimirMakaev wrote:
> 
>> I think there was an attempt in the past to build TypeSystemRust. Rust 
>> Project had a fork of LLDB with this implemented by Tom Tromey and CodeLLDB 
>> maintainer(vadimcn) has one. Both of them were not able to merge that into 
>> LLDB codebase. A relevant link to a discussion 
>> https://rust-lang.zulipchat.com/#narrow/stream/317568-t-compiler.2Fwg-debugging/topic/upstreaming.20rust.20support.20into.20lldb
>> 
>> Apart from just implementing type system itself (which is much bigger scope 
>> than this change) there are other non-trivial issues:
>> 
>> 1. There is no "compiler-as-a-service" in Rust so getting expressions to 
>> work is non-trivial. An interpreter of some sort needs to be built with 
>> subset of Rust support
>> 2. Infra changes (DEVOPS) changes are required to start building Rust 
>> inferiors to run tests on CI
>> 3. LLVM / rustc cross repository logistics. Rustc probably needs to live in 
>> LLVM to make this work well.
> 
> I know this is not exactly the focus of this patch, but I just wanted to 
> reply to this portion (since you've mentioned it). While some people did try 
> to suggest things like your points 2 and 3 in previous Rust support attempts, 
> I would say it seems impractical to require pulling a whole language 
> implementation into LLVM just to add debugging support. If LLDB really wants 
> to be a many-language debugger, I would strongly urge looking for testing 
> solutions that do not require somehow adding an full implementation of each 
> one into the tree. After all, the whole point of debug info formats like 
> DWARF is that the producer and consumer do not need to be tightly coupled 
> (since there's a standard format in between).
> 
> I would argue a more practical approach would involve test cases based on 
> whatever IR or AST might be appropriate for the feature under test, e.g. 
> DWARF output from Rust, Rust IR or MIR, etc. These things are just data, and 
> LLDB (and / or small helper tools) could process this data without the need 
> for an entire language implementation.
> 
> A discussion from 2019 
> (https://discourse.llvm.org/t/rust-support-in-lldb-again/53210) seemed to 
> potentially be open to such an idea, but perhaps it's worth starting a new 
> discussion thread focused on the testing requirements for language support in 
> LLDB which attempts to work out guidelines which allow for languages whose 
> implementations live outside of the LLVM tree.
> 

From our experience supporting other languages, It is not enough to write tests 
that check static predicates.  You need to run expressions and move the program 
around to test the expression parser, and runtime introspection features, etc.  
Imagine trying to write tests for stepping through Rust async dispatch w/o 
being able to run programs in the test suite...  

A sustainable language plugin is going to need those sorts of tests, and trying 
to write those tests w/o a compiler to build the test subjects will get really 
tedious very quickly.  So whatever people plan to do, you need to make it more 
testable than just "did I get the DWARF right".

IMO to make a supportable Rust plugin that wider testing has to go on in CI 
somewhere.  Note, that doesn't require a full copy of the Rust compiler in the 
llvm sources.   As Greg pointed out in that thread you mentioned, you can back 
the TypeSystemRust and the ExpressionParserRust with whatever implementation 
suits you, and if you can do that in a simpler way that doesn't involve the 
actual language implementation, that's fine.  

But I do think there needs to be bots & testing for the plugins that can rely 
on being able to build & test more complex scenarios than just what you can get 
from static analysis. Otherwise, all the people working on support for other 
languages are going to keep breaking the Rust implementation, which won't make 
for a productive community.

Jim

> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D149213/new/
> 
> https://reviews.llvm.org/D149213
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] b9541b6 - Fix the root directory completion test.

2023-07-17 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-07-17T10:52:29-07:00
New Revision: b9541b6707715b8ea07b47f453f001e698195b3e

URL: 
https://github.com/llvm/llvm-project/commit/b9541b6707715b8ea07b47f453f001e698195b3e
DIFF: 
https://github.com/llvm/llvm-project/commit/b9541b6707715b8ea07b47f453f001e698195b3e.diff

LOG: Fix the root directory completion test.

It was implicitly assumning that "/" would have no files in it, only
directories.  That's not true, for instance on macOS if you've navigated
to the root directory in the Finder...

Since we're assuming everything we check against is a directory, then we
need to filter the completion for that coming in.

Added: 


Modified: 
lldb/test/API/functionalities/completion/TestCompletion.py

Removed: 




diff  --git a/lldb/test/API/functionalities/completion/TestCompletion.py 
b/lldb/test/API/functionalities/completion/TestCompletion.py
index 4b413260279b9c..74fb83071ad4af 100644
--- a/lldb/test/API/functionalities/completion/TestCompletion.py
+++ b/lldb/test/API/functionalities/completion/TestCompletion.py
@@ -485,7 +485,7 @@ def test_completion_target_create_from_root_dir(self):
 "target create " + root_dir,
 list(
 filter(
-lambda x: os.path.exists(x),
+lambda x: os.path.exists(x) and os.path.isdir(x),
 map(lambda x: root_dir + x + os.sep, os.listdir(root_dir)),
 )
 ),



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 8402ad2 - Add a generic Process method to dump plugin history.

2023-07-11 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-07-11T12:33:22-07:00
New Revision: 8402ad23104b6b20f07596738b02a4ab101a8af9

URL: 
https://github.com/llvm/llvm-project/commit/8402ad23104b6b20f07596738b02a4ab101a8af9
DIFF: 
https://github.com/llvm/llvm-project/commit/8402ad23104b6b20f07596738b02a4ab101a8af9.diff

LOG: Add a generic Process method to dump plugin history.

I need to call this to figure out why the assert in
StopInfoMachException::CreateStopReasonWithMachException is triggering, but
it isn't appropriate to directly access the GDBRemoteCommunication there.  And
dumping whatever history the process plugin has collected during the run isn't
gdb-remote specific...

Differential Revision: https://reviews.llvm.org/D154992

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index dfed3659432df0..affd3fbc37b07a 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -575,6 +575,10 @@ class Process : public 
std::enable_shared_from_this,
   /// of CommandObject like CommandObjectRaw, CommandObjectParsed,
   /// or CommandObjectMultiword.
   virtual CommandObject *GetPluginCommandObject() { return nullptr; }
+  
+  /// The underlying plugin might store the low-level communication history for
+  /// this session.  Dump it into the provided stream.
+  virtual void DumpPluginHistory(Stream ) { return; }
 
   /// Launch a new process.
   ///

diff  --git a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp 
b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
index b4301f21ac1032..d60e6250c7c0ac 100644
--- a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
+++ b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
@@ -744,6 +744,7 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
   }
 }
   }
+  thread.GetProcess()->DumpPluginHistory(s);
   llvm::report_fatal_error(s.GetData());
   lldbassert(
   false &&

diff  --git 
a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
index 8ea93655d6bbf2..e8606ddae5674a 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
@@ -457,7 +457,7 @@ bool GDBRemoteRegisterContext::WriteRegisterBytes(const 
RegisterInfo *reg_info,
   if (log) {
 if (log->GetVerbose()) {
   StreamString strm;
-  gdb_comm.DumpHistory(strm);
+  process->DumpPluginHistory(strm);
   LLDB_LOGF(log,
 "error: failed to get packet sequence mutex, not sending "
 "write register for \"%s\":\n%s",
@@ -566,7 +566,7 @@ bool GDBRemoteRegisterContext::ReadAllRegisterValues(
 if (log) {
   if (log->GetVerbose()) {
 StreamString strm;
-gdb_comm.DumpHistory(strm);
+process->DumpPluginHistory(strm);
 LLDB_LOGF(log,
   "error: failed to get packet sequence mutex, not sending "
   "read all registers:\n%s",
@@ -741,7 +741,7 @@ bool GDBRemoteRegisterContext::WriteAllRegisterValues(
 if (log) {
   if (log->GetVerbose()) {
 StreamString strm;
-gdb_comm.DumpHistory(strm);
+process->DumpPluginHistory(strm);
 LLDB_LOGF(log,
   "error: failed to get packet sequence mutex, not sending "
   "write all registers:\n%s",

diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 522dee9f768620..b6f146fd872e80 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -113,7 +113,7 @@ void DumpProcessGDBRemotePacketHistory(void *p, const char 
*path) {
 return;
   }
   StreamFile stream(std::move(file.get()));
-  ((ProcessGDBRemote *)p)->GetGDBRemote().DumpHistory(stream);
+  ((Process *)p)->DumpPluginHistory(stream);
 }
 } // namespace lldb
 
@@ -205,6 +205,11 @@ lldb::ProcessSP ProcessGDBRemote::CreateInstance(
   return process_sp;
 }
 
+void ProcessGDBRemote::DumpPluginHistory(Stream ) {
+  GDBRemoteCommunicationClient _comm(GetGDBRemote());
+  gdb_comm.DumpHistory(s);
+}
+
 std::chrono::seconds ProcessGDBRemote::GetPacketTimeout() {
   return std::chrono::seconds(GetGlobalPluginProperties().GetPacketTimeout());
 }
@@ -5217,7 +5222,7 

[Lldb-commits] [lldb] c1885d2 - "settings set -g target.load-script-from-symbol-file" shouldn't crash.

2023-07-10 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-07-10T14:40:18-07:00
New Revision: c1885d2dfa950d0f78978546f92be15bc6cca474

URL: 
https://github.com/llvm/llvm-project/commit/c1885d2dfa950d0f78978546f92be15bc6cca474
DIFF: 
https://github.com/llvm/llvm-project/commit/c1885d2dfa950d0f78978546f92be15bc6cca474.diff

LOG: "settings set -g target.load-script-from-symbol-file" shouldn't crash.

-g is specified by passing in nullptr ExecutionContext, but in some
load-script-from-symbol-file specific code, the ExecutionContext was
asked for its Target w/o checking whether the pointer was null.

Fix that and add a test.

Added: 


Modified: 
lldb/source/Core/Debugger.cpp
lldb/test/API/commands/settings/TestSettings.py

Removed: 




diff  --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 3e92c125aa4ee6..4f06ed07274914 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -212,7 +212,7 @@ Status Debugger::SetPropertyValue(const ExecutionContext 
*exe_ctx,
 
   TargetSP target_sp;
   LoadScriptFromSymFile load_script_old_value = eLoadScriptFromSymFileFalse;
-  if (is_load_script && exe_ctx->GetTargetSP()) {
+  if (is_load_script && exe_ctx && exe_ctx->GetTargetSP()) {
 target_sp = exe_ctx->GetTargetSP();
 load_script_old_value =
 target_sp->TargetProperties::GetLoadScriptFromSymbolFile();

diff  --git a/lldb/test/API/commands/settings/TestSettings.py 
b/lldb/test/API/commands/settings/TestSettings.py
index 5c37264281c88b..7c90ef4ba2a446 100644
--- a/lldb/test/API/commands/settings/TestSettings.py
+++ b/lldb/test/API/commands/settings/TestSettings.py
@@ -971,3 +971,11 @@ def test_settings_api(self):
 
 # Test OptionValueLanguage
 self.verify_setting_value_json("repl-lang", "c++")
+
+def test_global_option(self):
+# This command used to crash the settings because -g was signaled by a
+# NULL execution context (not one with an empty Target...) and in the
+# special handling for load-script-from-symbol-file this wasn't 
checked.
+self.runCmd("settings set -g target.load-script-from-symbol-file true")
+
+  



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 01e3393 - Split up the runCmd trace printing to print the command before running.

2023-07-07 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-07-07T19:09:18-07:00
New Revision: 01e3393b94d194ee99e57f23f9c08160cef94753

URL: 
https://github.com/llvm/llvm-project/commit/01e3393b94d194ee99e57f23f9c08160cef94753
DIFF: 
https://github.com/llvm/llvm-project/commit/01e3393b94d194ee99e57f23f9c08160cef94753.diff

LOG: Split up the runCmd trace printing to print the command before running.
That way if the command crashes you still know what it was.

Differential Revision: https://reviews.llvm.org/D154752

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 2bff1a7067cb3d..02255712a8dd11 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -2059,12 +2059,14 @@ def runCmd(self, cmd, msg=None, check=True, 
trace=False, inHistory=False):
 running = cmd.startswith("run") or cmd.startswith("process launch")
 
 for i in range(self.maxLaunchCount if running else 1):
-self.ci.HandleCommand(cmd, self.res, inHistory)
-
 with recording(self, trace) as sbuf:
 print("runCmd:", cmd, file=sbuf)
 if not check:
 print("check of return status not required", file=sbuf)
+
+self.ci.HandleCommand(cmd, self.res, inHistory)
+
+with recording(self, trace) as sbuf:
 if self.res.Succeeded():
 print("output:", self.res.GetOutput(), file=sbuf)
 else:



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 2b0c886 - Refine the reporting mechanism for interruption.

2023-07-06 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-07-06T16:19:19-07:00
New Revision: 2b0c8865421287a30ddda0f459f17f76bfeb1358

URL: 
https://github.com/llvm/llvm-project/commit/2b0c8865421287a30ddda0f459f17f76bfeb1358
DIFF: 
https://github.com/llvm/llvm-project/commit/2b0c8865421287a30ddda0f459f17f76bfeb1358.diff

LOG: Refine the reporting mechanism for interruption.

Also, make it possible for new Targets which haven't been added to
the TargetList yet to check for interruption, and add a few more
places in building modules where we can check for interruption.

Differential Revision: https://reviews.llvm.org/D154542

Added: 


Modified: 
lldb/include/lldb/Core/Debugger.h
lldb/include/lldb/Target/TargetList.h
lldb/source/API/SBFrame.cpp
lldb/source/Commands/CommandCompletions.cpp
lldb/source/Commands/CommandObjectFrame.cpp
lldb/source/Commands/CommandObjectTarget.cpp
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Core/Debugger.cpp
lldb/source/Core/Module.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Target/StackFrameList.cpp
lldb/source/Target/Target.cpp
lldb/source/Target/TargetList.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 3996c4c58e2baf..239429b75c4260 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -43,6 +43,7 @@
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/DynamicLibrary.h"
+#include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/Threading.h"
 
 #include 
@@ -85,6 +86,8 @@ class Debugger : public 
std::enable_shared_from_this,
 eBroadcastSymbolChange = (1 << 3),
   };
 
+  using DebuggerList = std::vector;
+
   static ConstString GetStaticBroadcasterClass();
 
   /// Get the public broadcaster for this debugger.
@@ -411,12 +414,75 @@ class Debugger : public 
std::enable_shared_from_this,
   /// If you are on the RunCommandInterpreter thread, it will check the
   /// command interpreter state, and if it is on another thread it will
   /// check the debugger Interrupt Request state.
+  /// \param[in] cur_func
+  /// For reporting if the interruption was requested.  Don't provide this by
+  /// hand, use INTERRUPT_REQUESTED so this gets done consistently.
   ///
+  /// \param[in] formatv
+  /// A formatv string for the interrupt message.  If the elements of the 
+  /// message are expensive to compute, you can use the no-argument form of
+  /// InterruptRequested, then make up the report using REPORT_INTERRUPTION. 
+  /// 
   /// \return
   ///  A boolean value, if \b true an interruptible operation should interrupt
   ///  itself.
+  template 
+  bool InterruptRequested(const char *cur_func, 
+  const char *formatv, Args &&... args) {
+bool ret_val = InterruptRequested();
+if (ret_val) {
+  if (!formatv)
+formatv = "Unknown message";
+  if (!cur_func)
+cur_func = "";
+  ReportInterruption(InterruptionReport(cur_func, 
+llvm::formatv(formatv, 
+std::forward(args)...)));
+}
+return ret_val;
+  }
+  
+  
+  /// This handy define will keep you from having to generate a report for the
+  /// interruption by hand.  Use this except in the case where the arguments to
+  /// the message description are expensive to compute.
+#define INTERRUPT_REQUESTED(debugger, ...) \
+(debugger).InterruptRequested(__func__, __VA_ARGS__)
+
+  // This form just queries for whether to interrupt, and does no reporting:
   bool InterruptRequested();
+  
+  // FIXME: Do we want to capture a backtrace at the interruption point?
+  class InterruptionReport {
+  public:
+InterruptionReport(std::string function_name, std::string description) :
+m_function_name(std::move(function_name)), 
+m_description(std::move(description)),
+m_interrupt_time(std::chrono::system_clock::now()),
+m_thread_id(llvm::get_threadid()) {}
+
+InterruptionReport(std::string function_name, 
+const llvm::formatv_object_base );
+
+  template 
+  InterruptionReport(std::string function_name,
+  const char *format, Args &&... args) :
+InterruptionReport(function_name, llvm::formatv(format, 
std::forward(args)...)) {}
+
+std::string m_function_name;
+std::string m_description;
+const std::chrono::time_point m_interrupt_time;
+const uint64_t m_thread_id;
+  };
+  void ReportInterruption(const InterruptionReport );
+#define REPORT_INTERRUPTION(debugger, ...) \
+(debugger).ReportInterruption(Debugger::InterruptionReport(__func__, \
+__VA_ARGS__))
 
+  static DebuggerList DebuggersRequestingInterruption();
+
+public:
+  
   // This is for use in the command 

[Lldb-commits] [lldb] f05e2fb - Don't allow SBValue::Cast to cast from a smaller type to a larger,

2023-06-26 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-06-26T16:02:01-07:00
New Revision: f05e2fb013f0e2504471a9899dba7d70cc58a63d

URL: 
https://github.com/llvm/llvm-project/commit/f05e2fb013f0e2504471a9899dba7d70cc58a63d
DIFF: 
https://github.com/llvm/llvm-project/commit/f05e2fb013f0e2504471a9899dba7d70cc58a63d.diff

LOG: Don't allow SBValue::Cast to cast from a smaller type to a larger,
as we don't in general know where the extra data should come from.

Differential Revision: https://reviews.llvm.org/D153657

Added: 


Modified: 
lldb/include/lldb/Core/ValueObject.h
lldb/include/lldb/Core/ValueObjectConstResult.h
lldb/include/lldb/Core/ValueObjectConstResultCast.h
lldb/include/lldb/Core/ValueObjectConstResultChild.h
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/Core/ValueObject.cpp
lldb/source/Core/ValueObjectConstResult.cpp
lldb/source/Core/ValueObjectConstResultCast.cpp
lldb/source/Core/ValueObjectConstResultChild.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxx.cpp
lldb/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
lldb/test/API/python_api/value/TestValueAPI.py
lldb/test/API/python_api/value/main.c

Removed: 




diff  --git a/lldb/include/lldb/Core/ValueObject.h 
b/lldb/include/lldb/Core/ValueObject.h
index 2f2b212e238ca..2d8036ab07871 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -614,7 +614,9 @@ class ValueObject {
   virtual void SetLiveAddress(lldb::addr_t addr = LLDB_INVALID_ADDRESS,
   AddressType address_type = eAddressTypeLoad) {}
 
-  virtual lldb::ValueObjectSP Cast(const CompilerType _type);
+  lldb::ValueObjectSP Cast(const CompilerType _type);
+
+  virtual lldb::ValueObjectSP DoCast(const CompilerType _type);
 
   virtual lldb::ValueObjectSP CastPointerType(const char *name,
   CompilerType _type);

diff  --git a/lldb/include/lldb/Core/ValueObjectConstResult.h 
b/lldb/include/lldb/Core/ValueObjectConstResult.h
index 4edd495216061..d61df859bebce 100644
--- a/lldb/include/lldb/Core/ValueObjectConstResult.h
+++ b/lldb/include/lldb/Core/ValueObjectConstResult.h
@@ -106,7 +106,7 @@ class ValueObjectConstResult : public ValueObject {
 
   lldb::LanguageType GetPreferredDisplayLanguage() override;
 
-  lldb::ValueObjectSP Cast(const CompilerType _type) override;
+  lldb::ValueObjectSP DoCast(const CompilerType _type) override;
 
 protected:
   bool UpdateValue() override;

diff  --git a/lldb/include/lldb/Core/ValueObjectConstResultCast.h 
b/lldb/include/lldb/Core/ValueObjectConstResultCast.h
index 5467ce3db403f..efcbe0dc6a0bd 100644
--- a/lldb/include/lldb/Core/ValueObjectConstResultCast.h
+++ b/lldb/include/lldb/Core/ValueObjectConstResultCast.h
@@ -51,7 +51,7 @@ class ValueObjectConstResultCast : public ValueObjectCast {
   size_t GetPointeeData(DataExtractor , uint32_t item_idx = 0,
 uint32_t item_count = 1) override;
 
-  lldb::ValueObjectSP Cast(const CompilerType _type) override;
+  lldb::ValueObjectSP DoCast(const CompilerType _type) override;
 
 protected:
   ValueObjectConstResultImpl m_impl;

diff  --git a/lldb/include/lldb/Core/ValueObjectConstResultChild.h 
b/lldb/include/lldb/Core/ValueObjectConstResultChild.h
index 26bd9f337a595..7e9da14e8e97f 100644
--- a/lldb/include/lldb/Core/ValueObjectConstResultChild.h
+++ b/lldb/include/lldb/Core/ValueObjectConstResultChild.h
@@ -60,7 +60,7 @@ class ValueObjectConstResultChild : public ValueObjectChild {
   size_t GetPointeeData(DataExtractor , uint32_t item_idx = 0,
 uint32_t item_count = 1) override;
 
-  lldb::ValueObjectSP Cast(const CompilerType _type) override;
+  lldb::ValueObjectSP DoCast(const CompilerType _type) override;
 
 protected:
   ValueObjectConstResultImpl m_impl;

diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index a712f6b2b2a56..2bff1a7067cb3 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -2604,6 +2604,17 @@ def assertSuccess(self, obj, msg=None):
 if not obj.Success():
 error = obj.GetCString()
 self.fail(self._formatMessage(msg, "'{}' is not 
success".format(error)))
+"""Assert that an lldb.SBError is in the "failure" state."""
+
+def assertFailure(self, obj, error_str = None, msg=None):
+if obj.Success():
+self.fail(self._formatMessage(msg, "Error not in a fail state"))
+
+if error_str == None:
+return
+  
+error = obj.GetCString()
+self.assertEqual(error, error_str, msg)
 
 """Assert that a command return object is successful"""
 

diff  --git a/lldb/source/Core/ValueObject.cpp 
b/lldb/source/Core/ValueObject.cpp
index 9ff980db96d23..d60a1d6f7a105 100644

[Lldb-commits] [lldb] df1bb2e - Restrict the test from 22667e3220de5ead353a2148265d841644b63824

2023-06-01 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-06-01T18:45:45-07:00
New Revision: df1bb2e65bf4b2ca1140f4c9d19ff2a36ab94e6e

URL: 
https://github.com/llvm/llvm-project/commit/df1bb2e65bf4b2ca1140f4c9d19ff2a36ab94e6e
DIFF: 
https://github.com/llvm/llvm-project/commit/df1bb2e65bf4b2ca1140f4c9d19ff2a36ab94e6e.diff

LOG: Restrict the test from 22667e3220de5ead353a2148265d841644b63824

I fixed some long-standing failures in SBTarget::FindGlobalVariables
but the fix is in the the accelerator table lookups.  I fixed it in
the DWARF mappable tables but not everyone uses those, so I had to
restrict the test to systems I know did.

Added: 


Modified: 
lldb/test/API/lang/cpp/class_static/TestStaticVariables.py

Removed: 




diff  --git a/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py 
b/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
index 6fd4a8c9b301..c7e38feeb13c 100644
--- a/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
+++ b/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
@@ -128,7 +128,7 @@ def build_value_check(self, var_name, values):
 )
 @expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24764")
 @add_test_categories(["pyapi"])
-def test_with_python_api(self):
+def test_with_python_FindValue(self):
 """Test Python APIs on file and class static variables."""
 self.build()
 exe = self.getBuildArtifact("a.out")
@@ -194,6 +194,44 @@ def test_with_python_api(self):
 self.DebugSBValue(val)
 self.assertEqual(val.GetName(), "hello_world")
 
+# This test tests behavior that's been broken for a very long time..
+# The fix for it is in the accelerator table part of the DWARF reader,
+# and I fixed the version that the names accelerator uses, but I don't
+# know how to fix it on systems that don't use that. There isn't a
+# decorator for that - not sure how to construct that so I'm limiting the
+# test do Darwin for now.
+@expectedFailureAll(
+compiler=["gcc"], bugnumber="Compiler emits incomplete debug info"
+)
+@skipUnlessDarwin
+@add_test_categories(["pyapi"])
+def test_with_python_FindGlobalVariables(self):
+"""Test Python APIs on file and class static variables."""
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+breakpoint = target.BreakpointCreateByLocation("main.cpp", self.line)
+self.assertTrue(breakpoint, VALID_BREAKPOINT)
+
+# Now launch the process, and do not stop at entry point.
+process = target.LaunchSimple(None, None, 
self.get_process_working_directory())
+self.assertTrue(process, PROCESS_IS_VALID)
+
+# The stop reason of the thread should be breakpoint.
+thread = lldbutil.get_stopped_thread(process, 
lldb.eStopReasonBreakpoint)
+self.assertIsNotNone(thread)
+
+# Get the SBValue of 'A::g_points' and 'g_points'.
+frame = thread.GetFrameAtIndex(0)
+
+# Build ValueCheckers for the values we're going to find:
+value_check_A = self.build_value_check("A::g_points", ["1", "2", "11", 
"22"])
+value_check_none = self.build_value_check("g_points", ["3", "4", "33", 
"44"])
+value_check_AA = self.build_value_check("AA::g_points", ["5", "6", 
"55", "66"])
+
 # We should also be able to get class statics from FindGlobalVariables.
 # eMatchTypeStartsWith should only find A:: not AA::
 val_list = target.FindGlobalVariables("A::", 10, 
lldb.eMatchTypeStartsWith)
@@ -227,3 +265,4 @@ def test_with_python_api(self):
 # between file statics and globals:
 val_list = target.FindGlobalVariables("g_points", 10, 
lldb.eMatchTypeNormal)
 self.assertEqual(val_list.GetSize(), 3, "Found all three g_points")
+



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 22667e3 - Fix regex & startsWith name lookup in SBTarget::FindGlobalVariables

2023-06-01 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-06-01T16:15:06-07:00
New Revision: 22667e3220de5ead353a2148265d841644b63824

URL: 
https://github.com/llvm/llvm-project/commit/22667e3220de5ead353a2148265d841644b63824
DIFF: 
https://github.com/llvm/llvm-project/commit/22667e3220de5ead353a2148265d841644b63824.diff

LOG: Fix regex & startsWith name lookup in SBTarget::FindGlobalVariables

There were two bugs here.

eMatchTypeStartsWith searched for "symbol_name" by adding ".*" to the
end of the symbol name and treating that as a regex, which isn't
actually a regex for "starts with". The ".*" is in fact a no-op.  When
we finally get to comparing the name, we compare against whatever form
of the name was in the accelerator table. But for C++ that might be
the mangled name. We should also try demangled names here, since most
users are going the see demangled not mangled names.  I fixed these
two bugs and added a bunch of tests for FindGlobalVariables.

This change is in the DWARF parser code, so there may be a similar bug
in PDB, but the test for this was already skipped for Windows, so I
don't know about this.

You might theoretically need to do this Mangled comparison in

DWARFMappedHash::MemoryTable::FindByName

except when we have names we always chop them before looking them up
so I couldn't see any code paths that fail without that change. So I
didn't add that to this patch.

Differential Revision: https://reviews.llvm.org/D151940

Added: 


Modified: 
lldb/source/API/SBTarget.cpp
lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
lldb/test/API/lang/cpp/class_static/main.cpp

Removed: 




diff  --git a/lldb/source/API/SBTarget.cpp b/lldb/source/API/SBTarget.cpp
index 980cb7788bf51..53af5b1d7a477 100644
--- a/lldb/source/API/SBTarget.cpp
+++ b/lldb/source/API/SBTarget.cpp
@@ -1892,7 +1892,7 @@ SBValueList SBTarget::FindGlobalVariables(const char 
*name,
  max_matches, variable_list);
   break;
 case eMatchTypeStartsWith:
-  regexstr = llvm::Regex::escape(name) + ".*";
+  regexstr = "^" + llvm::Regex::escape(name) + ".*";
   target_sp->GetImages().FindGlobalVariables(RegularExpression(regexstr),
  max_matches, variable_list);
   break;

diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
index f530993381a93..9b1497d955bcf 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/HashedNameToDIE.cpp
@@ -9,6 +9,8 @@
 #include "HashedNameToDIE.h"
 #include "llvm/ADT/StringRef.h"
 
+#include "lldb/Core/Mangled.h"
+
 using namespace lldb_private::dwarf;
 
 bool DWARFMappedHash::ExtractDIEArray(
@@ -423,7 +425,11 @@ 
DWARFMappedHash::MemoryTable::AppendHashDataForRegularExpression(
   count * m_header.header_data.GetMinimumHashDataByteSize();
   if (count > 0 && m_data.ValidOffsetForDataOfSize(*hash_data_offset_ptr,
min_total_hash_data_size)) {
-const bool match = regex.Execute(llvm::StringRef(strp_cstr));
+// The name in the name table may be a mangled name, in which case we
+// should also compare against the demangled version.  The simplest way to
+// do that is to use the Mangled class:
+lldb_private::Mangled mangled_name((llvm::StringRef(strp_cstr)));
+const bool match = mangled_name.NameMatches(regex);
 
 if (!match && m_header.header_data.HashDataHasFixedByteSize()) {
   // If the regex doesn't match and we have fixed size data, we can just

diff  --git a/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py 
b/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
index 05c45142fec77..6fd4a8c9b3018 100644
--- a/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
+++ b/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
@@ -106,6 +106,20 @@ def test_with_run_command_complete(self):
 ],
 )
 
+def build_value_check(self, var_name, values):
+children_1 = [ValueCheck(name = "x", value = values[0], type = "int"),
+  ValueCheck(name = "y", value = values[1], type = "int")]
+children_2 = [ValueCheck(name = "x", value = values[2], type = "int"),
+  ValueCheck(name = "y", value = values[3], type = "int")]
+elem_0 = ValueCheck(name = "[0]", value=None, type = "PointType",
+children=children_1)
+elem_1 = ValueCheck(name = "[1]", value=None, type = "PointType",
+children=children_2)
+value_check = ValueCheck(name=var_name, value = None, type = 
"PointType[2]",
+ children = [elem_0, elem_1])
+
+return value_check
+
 

[Lldb-commits] [lldb] 267a4cd - Prevent some spurious error messages in the debugserver logs.

2023-06-01 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-06-01T10:21:23-07:00
New Revision: 267a4cda82481da159492bc6d6597d11101f8abb

URL: 
https://github.com/llvm/llvm-project/commit/267a4cda82481da159492bc6d6597d11101f8abb
DIFF: 
https://github.com/llvm/llvm-project/commit/267a4cda82481da159492bc6d6597d11101f8abb.diff

LOG: Prevent some spurious error messages in the debugserver logs.

DNBGetDeploymentInfo was calling GetPlatformString w/o checking that
the load command it was processing actually provided a platform string.
That caused a bunch of worrisome looking error messages in the debugserver
log output.

Differential Revision: https://reviews.llvm.org/D151861

Added: 


Modified: 
lldb/tools/debugserver/source/DNB.cpp

Removed: 




diff  --git a/lldb/tools/debugserver/source/DNB.cpp 
b/lldb/tools/debugserver/source/DNB.cpp
index 8a8b1eeb355bd..7b86ca0bfb9dc 100644
--- a/lldb/tools/debugserver/source/DNB.cpp
+++ b/lldb/tools/debugserver/source/DNB.cpp
@@ -1456,9 +1456,13 @@ DNBGetDeploymentInfo(nub_process_t pid, bool 
is_executable,
 major_version = info.major_version;
 minor_version = info.minor_version;
 patch_version = info.patch_version;
+// MachProcess::DeploymentInfo has a bool operator to tell whether we have
+// set the platform.  If that's not true, don't report out the platform:
+if (!info)
+  return {};
 return procSP->GetPlatformString(info.platform);
   }
-  return nullptr;
+  return {};
 }
 
 // Get the current shared library information for a process. Only return



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 620dc12 - Add EXC_SYSCALL to the set of ignorable mach exceptions.

2023-06-01 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-06-01T10:20:47-07:00
New Revision: 620dc1224ff9e4cb86e6e4d8e7c3941fc921887d

URL: 
https://github.com/llvm/llvm-project/commit/620dc1224ff9e4cb86e6e4d8e7c3941fc921887d
DIFF: 
https://github.com/llvm/llvm-project/commit/620dc1224ff9e4cb86e6e4d8e7c3941fc921887d.diff

LOG: Add EXC_SYSCALL to the set of ignorable mach exceptions.
Add some more tests of what exceptions we accept and don't accept.

Differential Revision: https://reviews.llvm.org/D151843

Added: 


Modified: 
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
lldb/test/API/macosx/ignore_exceptions/TestIgnoredExceptions.py

Removed: 




diff  --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index 60327fbe3124f..f3f0fd7de3751 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -63,7 +63,8 @@ static Status ExceptionMaskValidator(const char *string, void 
*unused) {
   || candidate == "EXC_BAD_INSTRUCTION"
   || candidate == "EXC_ARITHMETIC"
   || candidate == "EXC_RESOURCE"
-  || candidate == "EXC_GUARD")) {
+  || candidate == "EXC_GUARD"
+  || candidate == "EXC_SYSCALL")) {
   error.SetErrorStringWithFormat("invalid exception type: '%s'",
   candidate.str().c_str());
   return error;

diff  --git a/lldb/test/API/macosx/ignore_exceptions/TestIgnoredExceptions.py 
b/lldb/test/API/macosx/ignore_exceptions/TestIgnoredExceptions.py
index 677e6315123fc..429f1dbb1beba 100644
--- a/lldb/test/API/macosx/ignore_exceptions/TestIgnoredExceptions.py
+++ b/lldb/test/API/macosx/ignore_exceptions/TestIgnoredExceptions.py
@@ -30,10 +30,22 @@ def suspended_thread_test(self):
 "EXC_BAD_AXESS",
 error=True,
 )
-# Now set ourselves to ignore some exceptions.  The test depends on 
ignoring EXC_BAD_ACCESS, but I passed a couple
-# to make sure they parse:
+# Make sure that we don't accept exceptions that lldb/debugserver need:
+self.match(
+"settings set platform.plugin.darwin.ignored-exceptions 
EXC_BREAKPOINT",
+"EXC_BREAKPOINT",
+error=True,
+)
+# Make sure that we don't accept exceptions that lldb/debugserver need:
+self.match(
+"settings set platform.plugin.darwin.ignored-exceptions 
EXC_SOFT_SIGNAL",
+"EXC_SOFT_SIGNAL",
+error=True,
+)
+# Now set ourselves to ignore some exceptions.  The test depends on 
ignoring EXC_BAD_ACCESS, but I passed all the
+# ones we currently accept to make sure they parse:
 self.runCmd(
-"settings set platform.plugin.darwin.ignored-exceptions 
EXC_BAD_ACCESS|EXC_ARITHMETIC"
+"settings set platform.plugin.darwin.ignored-exceptions 
EXC_BAD_ACCESS|EXC_BAD_INSTRUCTION|EXC_ARITHMETIC|EXC_RESOURCE|EXC_GUARD|EXC_SYSCALL"
 )
 (target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
 self, "Stop here to get things going", self.main_source_file



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 1418677 - Fix SBValue::FindValue for file static variables

2023-05-30 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-05-30T17:12:35-07:00
New Revision: 14186773e79b8c6787afac2f9ee69738151377ec

URL: 
https://github.com/llvm/llvm-project/commit/14186773e79b8c6787afac2f9ee69738151377ec
DIFF: 
https://github.com/llvm/llvm-project/commit/14186773e79b8c6787afac2f9ee69738151377ec.diff

LOG: Fix SBValue::FindValue for file static variables

This was just a thinko. The API StackFrame::GetVariableList takes a
bool for "get_file_globals" which if true will also find file statics
and file globals. But we only were passing that as true if the
ValueType was eValueTypeVariableGlobal, which meant that we never find
file statics. It's okay if we cast too wide a net when we do
GetVariableList as later on we check against the ValueType to filter
globals from statics.

There was a test that had a whole bunch of globals and tested
FindValue on all of them, but had no statics. So I just made one of
the globals a file static, which verifies the fix.

Differential Revision: https://reviews.llvm.org/D151392

Added: 


Modified: 
lldb/source/API/SBFrame.cpp
lldb/test/API/python_api/process/TestProcessAPI.py
lldb/test/API/python_api/process/main.cpp

Removed: 




diff  --git a/lldb/source/API/SBFrame.cpp b/lldb/source/API/SBFrame.cpp
index 285469c1063b3..e31297446007a 100644
--- a/lldb/source/API/SBFrame.cpp
+++ b/lldb/source/API/SBFrame.cpp
@@ -602,7 +602,8 @@ SBValue SBFrame::FindValue(const char *name, ValueType 
value_type,
 stop_if_block_is_inlined_function,
 [frame](Variable *v) { return v->IsInScope(frame); },
 _list);
-  if (value_type == eValueTypeVariableGlobal) {
+  if (value_type == eValueTypeVariableGlobal 
+  || value_type == eValueTypeVariableStatic) {
 const bool get_file_globals = true;
 VariableList *frame_vars = frame->GetVariableList(get_file_globals,
   nullptr);

diff  --git a/lldb/test/API/python_api/process/TestProcessAPI.py 
b/lldb/test/API/python_api/process/TestProcessAPI.py
index df41397eb32b8..65330e5163f72 100644
--- a/lldb/test/API/python_api/process/TestProcessAPI.py
+++ b/lldb/test/API/python_api/process/TestProcessAPI.py
@@ -49,8 +49,8 @@ def test_read_memory(self):
 )
 frame = thread.GetFrameAtIndex(0)
 
-# Get the SBValue for the global variable 'my_char'.
-val = frame.FindValue("my_char", lldb.eValueTypeVariableGlobal)
+# Get the SBValue for the file static variable 'my_char'.
+val = frame.FindValue("my_char", lldb.eValueTypeVariableStatic)
 self.DebugSBValue(val)
 
 # Due to the typemap magic (see lldb.swig), we pass in 1 to ReadMemory 
and
@@ -149,8 +149,8 @@ def test_write_memory(self):
 )
 frame = thread.GetFrameAtIndex(0)
 
-# Get the SBValue for the global variable 'my_char'.
-val = frame.FindValue("my_char", lldb.eValueTypeVariableGlobal)
+# Get the SBValue for the static variable 'my_char'.
+val = frame.FindValue("my_char", lldb.eValueTypeVariableStatic)
 self.DebugSBValue(val)
 
 # If the variable does not have a load address, there's no sense

diff  --git a/lldb/test/API/python_api/process/main.cpp 
b/lldb/test/API/python_api/process/main.cpp
index 07cde05e2a054..54bf3590ad431 100644
--- a/lldb/test/API/python_api/process/main.cpp
+++ b/lldb/test/API/python_api/process/main.cpp
@@ -3,7 +3,7 @@
 
 // This simple program is to test the lldb Python API related to process.
 
-char my_char = 'u';
+static char my_char = 'u';
 char my_cstring[] = "lldb.SBProcess.ReadCStringFromMemory() works!";
 char *my_char_ptr = (char *)"Does it work?";
 uint32_t my_uint32 = 12345;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] e19387e - We can't let GetStackFrameCount get interrupted or it will give the

2023-05-11 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-05-11T14:48:54-07:00
New Revision: e19387e6936c9ccc6200b32f3affea7b1020664c

URL: 
https://github.com/llvm/llvm-project/commit/e19387e6936c9ccc6200b32f3affea7b1020664c
DIFF: 
https://github.com/llvm/llvm-project/commit/e19387e6936c9ccc6200b32f3affea7b1020664c.diff

LOG: We can't let GetStackFrameCount get interrupted or it will give the
wrong answer. Plus, it's useful in some places to have a way to force
the full stack to be created even in the face of
interruption. Moreover, most of the time when you're just getting
frames, you don't need to know the number of frames in the stack to
start with. You just keep calling
Thread::GetStackFrameAtIndex(index++) and when you get a null
StackFrameSP back, you're done. That's also more amenable to
interruption if you are doing some work frame by frame.

So this patch makes GetStackFrameCount always return the full count,
suspending interruption. I also went through all the places that use
GetStackFrameCount to make sure that they really needed the full stack
walk. In many cases, they did not. For instance frame select -r 10 was
getting the number of frames just to check whether cur_frame_idx + 10
was within the stack. It's better in that case to see if that frame
exists first, since that doesn't force a full stack walk, and only
deal with walking off the end of the stack if it doesn't...

I also added a test for some of these behaviors.

Differential Revision: https://reviews.llvm.org/D150236

Added: 
lldb/test/API/functionalities/bt-interrupt/Makefile
lldb/test/API/functionalities/bt-interrupt/TestInterruptBacktrace.py
lldb/test/API/functionalities/bt-interrupt/main.c

Modified: 
lldb/include/lldb/Target/StackFrameList.h
lldb/include/lldb/lldb-private-enumerations.h
lldb/source/Commands/CommandCompletions.cpp
lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
lldb/source/Target/StackFrameList.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/StackFrameList.h 
b/lldb/include/lldb/Target/StackFrameList.h
index e0bc210298fbe..88e211ff692bd 100644
--- a/lldb/include/lldb/Target/StackFrameList.h
+++ b/lldb/include/lldb/Target/StackFrameList.h
@@ -100,7 +100,11 @@ class StackFrameList {
 
   bool SetFrameAtIndex(uint32_t idx, lldb::StackFrameSP _sp);
 
-  void GetFramesUpTo(uint32_t end_idx);
+  /// Realizes frames up to (and including) end_idx (which can be greater than 
 
+  /// the actual number of frames.)  
+  /// Returns true if the function was interrupted, false otherwise.
+  bool GetFramesUpTo(uint32_t end_idx, 
+  InterruptionControl allow_interrupt = AllowInterruption);
 
   void GetOnlyConcreteFramesUpTo(uint32_t end_idx, Unwind );
 

diff  --git a/lldb/include/lldb/lldb-private-enumerations.h 
b/lldb/include/lldb/lldb-private-enumerations.h
index 4fae9e6e38ff6..7f98220f9f164 100644
--- a/lldb/include/lldb/lldb-private-enumerations.h
+++ b/lldb/include/lldb/lldb-private-enumerations.h
@@ -274,4 +274,9 @@ enum SelectMostRelevant : bool {
   DoNoSelectMostRelevantFrame = false,
 };
 
+enum InterruptionControl : bool {
+  AllowInterruption = true,
+  DoNotAllowInterruption = false,
+};
+
 #endif // LLDB_LLDB_PRIVATE_ENUMERATIONS_H

diff  --git a/lldb/source/Commands/CommandCompletions.cpp 
b/lldb/source/Commands/CommandCompletions.cpp
index a3c9cf78dfe1a..bacb00cfe35ff 100644
--- a/lldb/source/Commands/CommandCompletions.cpp
+++ b/lldb/source/Commands/CommandCompletions.cpp
@@ -718,10 +718,14 @@ void CommandCompletions::FrameIndexes(CommandInterpreter 
,
 return;
 
   lldb::ThreadSP thread_sp = exe_ctx.GetThreadSP();
+  Debugger  = interpreter.GetDebugger();
   const uint32_t frame_num = thread_sp->GetStackFrameCount();
   for (uint32_t i = 0; i < frame_num; ++i) {
 lldb::StackFrameSP frame_sp = thread_sp->GetStackFrameAtIndex(i);
 StreamString strm;
+// Dumping frames can be slow, allow interruption.
+if (dbg.InterruptRequested())
+  break;
 frame_sp->Dump(, false, true);
 request.TryCompleteCurrentArg(std::to_string(i), strm.GetString());
   }

diff  --git a/lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp 
b/lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
index 5ce85f47072e9..ae5e1b7baed57 100644
--- a/lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
+++ b/lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
@@ -220,8 +220,7 @@ void SystemRuntimeMacOSX::AddThreadExtendedInfoPacketHints(
 }
 
 bool SystemRuntimeMacOSX::SafeToCallFunctionsOnThisThread(ThreadSP thread_sp) {
-  if (thread_sp && thread_sp->GetStackFrameCount() > 0 &&
-  thread_sp->GetFrameWithConcreteFrameIndex(0)) {
+  if (thread_sp && thread_sp->GetFrameWithConcreteFrameIndex(0)) {
 const SymbolContext sym_ctx(
 thread_sp->GetFrameWithConcreteFrameIndex(0)->GetSymbolContext(
 eSymbolContextSymbol));

diff 

[Lldb-commits] [lldb] 7b5dc63 - When the Debugger runs HandleProcessEvent it should allow

2023-05-10 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-05-10T15:40:40-07:00
New Revision: 7b5dc63fc4464e777e4210a68120b36cb283a9fd

URL: 
https://github.com/llvm/llvm-project/commit/7b5dc63fc4464e777e4210a68120b36cb283a9fd
DIFF: 
https://github.com/llvm/llvm-project/commit/7b5dc63fc4464e777e4210a68120b36cb283a9fd.diff

LOG: When the Debugger runs HandleProcessEvent it should allow
selecting the "Most relevant" frame.

If you don't do that, then the correct frame gets selected, but it
happens AFTER the frame info gets printed in the stop message, so
you don't see the selected frame.

The test for this hid the issue because it ran `frame info` and
checked the result of that.  That happens after the recognizer selects
the frame, and so it was right.  But if the recognizer is working
correctly it will have already done the same printing in the stop
message, and this way we also verify that the stop message was right.

Differential Revision: https://reviews.llvm.org/D150315

Added: 


Modified: 
lldb/source/Core/Debugger.cpp
lldb/test/Shell/Recognizer/assert.test

Removed: 




diff  --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index fbfee28183dd0..e39879953820f 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -1699,8 +1699,10 @@ void Debugger::HandleProcessEvent(const EventSP 
_sp) {
 
 // Display running state changes first before any STDIO
 if (got_state_changed && !state_is_stopped) {
+  // This is a public stop which we are going to announce to the user, so 
+  // we should force the most relevant frame selection here.
   Process::HandleProcessStateChangedEvent(event_sp, output_stream_sp.get(),
-  DoNoSelectMostRelevantFrame,
+  SelectMostRelevantFrame,
   pop_process_io_handler);
 }
 
@@ -1740,7 +1742,7 @@ void Debugger::HandleProcessEvent(const EventSP 
_sp) {
 // Now display any stopped state changes after any STDIO
 if (got_state_changed && state_is_stopped) {
   Process::HandleProcessStateChangedEvent(event_sp, output_stream_sp.get(),
-  DoNoSelectMostRelevantFrame,
+  SelectMostRelevantFrame,
   pop_process_io_handler);
 }
 

diff  --git a/lldb/test/Shell/Recognizer/assert.test 
b/lldb/test/Shell/Recognizer/assert.test
index 3e302ee403382..201e834cf357e 100644
--- a/lldb/test/Shell/Recognizer/assert.test
+++ b/lldb/test/Shell/Recognizer/assert.test
@@ -9,7 +9,6 @@
 # RUN: %lldb -b -s %s %t.out | FileCheck %s
 run
 # CHECK: thread #{{.*}}stop reason = hit program assert
-frame info
 # CHECK: frame #{{.*}}`main at assert.c
 frame recognizer info 0
 # CHECK: frame 0 is recognized by Assert StackFrame Recognizer



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] c2be702 - Allow scripted thread plans to modify the thread stop description when

2023-05-03 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-05-03T10:52:12-07:00
New Revision: c2be702104284cb3facf31124494b9a400296179

URL: 
https://github.com/llvm/llvm-project/commit/c2be702104284cb3facf31124494b9a400296179
DIFF: 
https://github.com/llvm/llvm-project/commit/c2be702104284cb3facf31124494b9a400296179.diff

LOG: Allow scripted thread plans to modify the thread stop description when
they are completed.

Added: 


Modified: 
lldb/bindings/python/python-wrapper.swig
lldb/examples/python/scripted_step.py
lldb/include/lldb/Interpreter/ScriptInterpreter.h
lldb/include/lldb/Target/ThreadPlanPython.h
lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
lldb/source/Target/ThreadPlanPython.cpp
lldb/test/API/functionalities/step_scripted/Steps.py
lldb/test/API/functionalities/step_scripted/TestStepScripted.py
lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Removed: 




diff  --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index d339f592cec4c..bb452658a8380 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -367,6 +367,38 @@ bool lldb_private::LLDBSWIGPythonCallThreadPlan(
   return false;
 }
 
+bool lldb_private::LLDBSWIGPythonCallThreadPlan(
+void *implementor, const char *method_name, lldb_private::Stream *stream,
+bool _error) {
+  got_error = false;
+
+  PyErr_Cleaner py_err_cleaner(false);
+  PythonObject self(PyRefType::Borrowed, static_cast(implementor));
+  auto pfunc = self.ResolveName(method_name);
+
+  if (!pfunc.IsAllocated()) 
+return false;
+
+  auto *sb_stream = new lldb::SBStream();
+  PythonObject sb_stream_arg =
+  ToSWIGWrapper(std::unique_ptr(sb_stream));
+
+  PythonObject result;
+  result = pfunc(sb_stream_arg);
+
+  if (PyErr_Occurred()) {
+printf("Error occured for call to %s.\n",
+   method_name);
+PyErr_Print();
+got_error = true;
+return false;
+  }
+  if (stream)
+stream->PutCString(sb_stream->GetData());
+  return true;
+
+}
+
 PythonObject lldb_private::LLDBSwigPythonCreateScriptedBreakpointResolver(
 const char *python_class_name, const char *session_dictionary_name,
 const StructuredDataImpl _impl,

diff  --git a/lldb/examples/python/scripted_step.py 
b/lldb/examples/python/scripted_step.py
index 011e24d70cb26..6e53072e9735c 100644
--- a/lldb/examples/python/scripted_step.py
+++ b/lldb/examples/python/scripted_step.py
@@ -77,6 +77,10 @@
 #is stale.  In this case, if the step_out plan that the 
FinishPrintAndContinue
 #plan is driving is stale, so is ours, and it is time to do our printing.
 #
+# 4) If you implement the "stop_description(SBStream stream)" method in your
+#python class, then that will show up as the "plan completed" reason when
+#your thread plan is complete.
+#
 # Both examples show stepping through an address range for 20 bytes from the
 # current PC.  The first one does it by single stepping and checking a 
condition.
 # It doesn't, however handle the case where you step into another frame while
@@ -122,6 +126,8 @@ def should_stop(self, event):
 def should_step(self):
 return True
 
+def stop_description(self, stream):
+stream.Print("Simple step completed")
 
 class StepWithPlan:
 
@@ -146,6 +152,9 @@ def should_stop(self, event):
 def should_step(self):
 return False
 
+def stop_description(self, stream):
+self.step_thread_plan.GetDescription(stream, 
lldb.eDescriptionLevelBrief)
+
 # Here's another example which does "step over" through the current function,
 # and when it stops at each line, it checks some condition (in this example the
 # value of a variable) and stops if that condition is true.
@@ -205,6 +214,9 @@ def should_stop(self, event):
 def should_step(self):
 return True
 
+def stop_description(self, stream):
+stream.Print(f"Stepped until a == 20")
+
 # Here's an example that steps out of the current frame, gathers some 
information
 # and then continues.  The information in this case is rax.  Currently the 
thread
 # plans are not a safe place to call lldb command-line commands, so the 
information
@@ -242,3 +254,6 @@ def do_print(self):
 print("RAX on exit: ", rax_value.GetValue())
 else:
 print("Couldn't get rax value:", rax_value.GetError().GetCString())
+
+def stop_description(self, stream):
+self.step_out_thread_plan.GetDescription(stream, 
lldb.eDescriptionLevelBrief)

diff  --git a/lldb/include/lldb/Interpreter/ScriptInterpreter.h 
b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
index aeb822e148c77..0095905fd320c 100644
--- a/lldb/include/lldb/Interpreter/ScriptInterpreter.h

[Lldb-commits] [lldb] 930c8ac - Improve the help output for `type XXX delete` where XXX is summary, format,

2023-05-01 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-05-01T14:21:27-07:00
New Revision: 930c8ac5f56122251fc5fe7cb8584360924af62f

URL: 
https://github.com/llvm/llvm-project/commit/930c8ac5f56122251fc5fe7cb8584360924af62f
DIFF: 
https://github.com/llvm/llvm-project/commit/930c8ac5f56122251fc5fe7cb8584360924af62f.diff

LOG: Improve the help output for `type XXX delete` where XXX is summary, format,
etc...

Differential Revision: https://reviews.llvm.org/D148282

Added: 


Modified: 
lldb/source/Commands/CommandObjectType.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectType.cpp 
b/lldb/source/Commands/CommandObjectType.cpp
index ae52808793660..2c2973a6272f3 100644
--- a/lldb/source/Commands/CommandObjectType.cpp
+++ b/lldb/source/Commands/CommandObjectType.cpp
@@ -39,9 +39,6 @@
 #include 
 #include 
 
-#define CHECK_FORMATTER_KIND_MASK(VAL) 
\
-  ((m_formatter_kind_mask & (VAL)) == (VAL))
-
 using namespace lldb;
 using namespace lldb_private;
 
@@ -100,6 +97,22 @@ static bool WarnOnPotentialUnquotedUnsignedType(Args 
,
   return false;
 }
 
+const char *FormatCategoryToString(FormatCategoryItem item, bool long_name) {
+  switch (item) {
+  case eFormatCategoryItemSummary:
+return "summary";
+  case eFormatCategoryItemFilter:
+return "filter";
+  case eFormatCategoryItemSynth:
+if (long_name)
+  return "synthetic child provider";
+return "synthetic";
+  case eFormatCategoryItemFormat:
+return "format";
+  }
+  llvm_unreachable("Fully covered switch above!");
+};
+
 #define LLDB_OPTIONS_type_summary_add
 #include "CommandOptions.inc"
 
@@ -754,16 +767,25 @@ class CommandObjectTypeFormatterDelete : public 
CommandObjectParsed {
   };
 
   CommandOptions m_options;
-  uint32_t m_formatter_kind_mask;
+  FormatCategoryItem m_formatter_kind;
 
   Options *GetOptions() override { return _options; }
+  
+  static constexpr const char *g_short_help_template  = 
+  "Delete an existing %s for a type.";
+
+  static constexpr const char *g_long_help_template =  
+  "Delete an existing %s for a type.  Unless you specify a "
+  "specific category or all categories, only the "
+  "'default' category is searched.  The names must be exactly as "
+  "shown in the 'type %s list' output";
 
 public:
   CommandObjectTypeFormatterDelete(CommandInterpreter ,
-   uint32_t formatter_kind_mask,
-   const char *name, const char *help)
-  : CommandObjectParsed(interpreter, name, help, nullptr),
-m_formatter_kind_mask(formatter_kind_mask) {
+   FormatCategoryItem formatter_kind)
+  : CommandObjectParsed(interpreter, 
+FormatCategoryToString(formatter_kind, false)),
+m_formatter_kind(formatter_kind) {
 CommandArgumentEntry type_arg;
 CommandArgumentData type_style_arg;
 
@@ -773,6 +795,19 @@ class CommandObjectTypeFormatterDelete : public 
CommandObjectParsed {
 type_arg.push_back(type_style_arg);
 
 m_arguments.push_back(type_arg);
+
+const char *kind = FormatCategoryToString(formatter_kind, true);
+const char *short_kind = FormatCategoryToString(formatter_kind, false);
+  
+StreamString s;
+s.Printf(g_short_help_template, kind);
+SetHelp(s.GetData());
+s.Clear();
+s.Printf(g_long_help_template, kind, short_kind);
+SetHelpLong(s.GetData());
+s.Clear();
+s.Printf("type %s delete", short_kind);
+SetCommandName(s.GetData());
   }
 
   ~CommandObjectTypeFormatterDelete() override = default;
@@ -785,7 +820,7 @@ class CommandObjectTypeFormatterDelete : public 
CommandObjectParsed {
 
 DataVisualization::Categories::ForEach(
 [this, ](const lldb::TypeCategoryImplSP _sp) {
-  category_sp->AutoComplete(request, m_formatter_kind_mask);
+  category_sp->AutoComplete(request, m_formatter_kind);
   return true;
 });
   }
@@ -812,7 +847,7 @@ class CommandObjectTypeFormatterDelete : public 
CommandObjectParsed {
 if (m_options.m_delete_all) {
   DataVisualization::Categories::ForEach(
   [this, typeCS](const lldb::TypeCategoryImplSP _sp) -> bool {
-category_sp->Delete(typeCS, m_formatter_kind_mask);
+category_sp->Delete(typeCS, m_formatter_kind);
 return true;
   });
   result.SetStatus(eReturnStatusSuccessFinishNoResult);
@@ -827,14 +862,14 @@ class CommandObjectTypeFormatterDelete : public 
CommandObjectParsed {
   DataVisualization::Categories::GetCategory(m_options.m_language,
  category);
   if (category)
-delete_category = category->Delete(typeCS, m_formatter_kind_mask);
+delete_category = category->Delete(typeCS, m_formatter_kind);
   extra_deletion = 

[Lldb-commits] [lldb] 47f72ae - Make the TSan report capture data structure anonymous.

2023-04-27 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-04-27T17:36:31-07:00
New Revision: 47f72aede163348ee474be4a3004dc0a9195fa9c

URL: 
https://github.com/llvm/llvm-project/commit/47f72aede163348ee474be4a3004dc0a9195fa9c
DIFF: 
https://github.com/llvm/llvm-project/commit/47f72aede163348ee474be4a3004dc0a9195fa9c.diff

LOG: Make the TSan report capture data structure anonymous.

This was using `struct data` which is way to common a name to use in
an lldb expression, and was causing occasional failures in the
TSan report gatherer.  The structure doesn't need to have a tag,
so remove it to avoid future problems.

The same job was done for the other sanitizers in D145569, but this
one was overlooked.

Differential Revision: https://reviews.llvm.org/D149394

Added: 


Modified: 

lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
 
b/lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
index cebe8d844160..946e4b356a36 100644
--- 
a/lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
+++ 
b/lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
@@ -94,7 +94,7 @@ const char *thread_sanitizer_retrieve_report_data_command = 
R"(
 const int REPORT_TRACE_SIZE = 128;
 const int REPORT_ARRAY_SIZE = 4;
 
-struct data {
+struct {
 void *report;
 const char *description;
 int report_count;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 076341d - Make sure SelectMostRelevantFrame happens only when returning to the user.

2023-04-21 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-04-21T14:21:25-07:00
New Revision: 076341d1088b0b3e0140178760dc45ac5162cd65

URL: 
https://github.com/llvm/llvm-project/commit/076341d1088b0b3e0140178760dc45ac5162cd65
DIFF: 
https://github.com/llvm/llvm-project/commit/076341d1088b0b3e0140178760dc45ac5162cd65.diff

LOG: Make sure SelectMostRelevantFrame happens only when returning to the user.

This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop somewhere where that's
helpful. For instance, stopping in pthread_kill after an assert will select
the assert frame.

This is not something you want to have happen internally in lldb, both
because internally you really don't want the selected frame changing out
from under you, and because the recognizers can do arbitrary work, and that
can cause deadlocks or other unexpected behavior.

However, it's not something that the current code does
explicitly after a stop has been delivered, it's expected to happen implicitly
as part of stopping. I changing this to call SMRF explicitly after a user
stop, but that got pretty ugly quickly.

So I added a bool to control whether to run this and audited all the current
uses to determine whether we're returning to the user or not.

Differential Revision: https://reviews.llvm.org/D148863

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Target/StackFrameList.h
lldb/include/lldb/Target/Thread.h
lldb/include/lldb/lldb-private-enumerations.h
lldb/source/API/SBThread.cpp
lldb/source/Commands/CommandObjectFrame.cpp
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Commands/CommandObjectType.cpp
lldb/source/Core/Debugger.cpp
lldb/source/Core/IOHandlerCursesGUI.cpp
lldb/source/Core/ValueObject.cpp
lldb/source/Expression/REPL.cpp

lldb/source/Plugins/InstrumentationRuntime/ASan/InstrumentationRuntimeASan.cpp

lldb/source/Plugins/InstrumentationRuntime/MainThreadChecker/InstrumentationRuntimeMainThreadChecker.cpp

lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp

lldb/source/Plugins/InstrumentationRuntime/UBSan/InstrumentationRuntimeUBSan.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
lldb/source/Plugins/MemoryHistory/asan/MemoryHistoryASan.cpp
lldb/source/Target/ExecutionContext.cpp
lldb/source/Target/Platform.cpp
lldb/source/Target/Process.cpp
lldb/source/Target/StackFrameList.cpp
lldb/source/Target/StopInfo.cpp
lldb/source/Target/Target.cpp
lldb/source/Target/Thread.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 0c90078accfc..808226067d5a 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -832,6 +832,7 @@ class Process : public 
std::enable_shared_from_this,
   /// \see Thread:Suspend()
   Status Resume();
 
+  /// Resume a process, and wait for it to stop.
   Status ResumeSynchronous(Stream *stream);
 
   /// Halts a running process.
@@ -2167,12 +2168,17 @@ class Process : public 
std::enable_shared_from_this,
   // process is hijacked and use_run_lock is true (the default), then this
   // function releases the run lock after the stop. Setting use_run_lock to
   // false will avoid this behavior.
+  // If we are waiting to stop that will return control to the user,
+  // then we also want to run SelectMostRelevantFrame, which is controlled
+  // by "select_most_relevant".
   lldb::StateType
   WaitForProcessToStop(const Timeout ,
lldb::EventSP *event_sp_ptr = nullptr,
bool wait_always = true,
lldb::ListenerSP hijack_listener = lldb::ListenerSP(),
-   Stream *stream = nullptr, bool use_run_lock = true);
+   Stream *stream = nullptr, bool use_run_lock = true,
+   SelectMostRelevant select_most_relevant =
+   DoNoSelectMostRelevantFrame);
 
   uint32_t GetIOHandlerID() const { return m_iohandler_sync.GetValue(); }
 
@@ -2210,9 +2216,10 @@ class Process : public 
std::enable_shared_from_this,
   /// \return
   /// \b true if the event describes a process state changed event, \b 
false
   /// otherwise.
-  static bool HandleProcessStateChangedEvent(const lldb::EventSP _sp,
- Stream *stream,
- bool _process_io_handler);
+  static bool
+  HandleProcessStateChangedEvent(const lldb::EventSP _sp, Stream *stream,
+ SelectMostRelevant select_most_relevant,
+ bool _process_io_handler);
 
   Event *PeekAtStateChangedEvents();
 

diff  --git a/lldb/include/lldb/Target/StackFrameList.h 

[Lldb-commits] [lldb] f79c037 - Fix the check in StopInfoBreakpoint for "are we currently running an expression"

2023-04-05 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-04-05T17:14:25-07:00
New Revision: f79c037b63278bc5b4481a1a55c68e42f0ea1461

URL: 
https://github.com/llvm/llvm-project/commit/f79c037b63278bc5b4481a1a55c68e42f0ea1461
DIFF: 
https://github.com/llvm/llvm-project/commit/f79c037b63278bc5b4481a1a55c68e42f0ea1461.diff

LOG: Fix the check in StopInfoBreakpoint for "are we currently running an 
expression"

We were checking "WasTheLastResumeForUserExpression" but that returns true even
if that expression was completed, provided we haven't run again.  This uses a
better check.

This is actually fairly hard to trigger.  It happens the first time you hit an
objc_exception_throw breakpoint and invoke that frame recognizer for that.  But
I couldn't trigger it using a Python based frame recognizer.  So I wrote a test
for the objc_exception_throw_breakpoint recognizer which should have been there
anyway...  It fails (the target auto-continues) w/o this patch and succeeds with
it.

Differential Revision: https://reviews.llvm.org/D147587

Added: 
lldb/test/API/macosx/objc_exception_recognizer/Makefile
lldb/test/API/macosx/objc_exception_recognizer/TestObjCRecognizer.py
lldb/test/API/macosx/objc_exception_recognizer/main.m

Modified: 
lldb/include/lldb/Target/Process.h
lldb/source/Target/StopInfo.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 3ffacb52299b9..1857dd0a7ada9 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -284,6 +284,13 @@ class ProcessModID {
 return m_resume_id == m_last_user_expression_resume;
   }
 
+  bool IsRunningExpression() const {
+// Don't return true if we are no longer running an expression:
+if (m_running_user_expression || m_running_utility_function)
+  return true;
+return false;
+  }
+
   void SetRunningUserExpression(bool on) {
 if (on)
   m_running_user_expression++;

diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index a98fc28c7338d..9fd0e0a5674ec 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -332,7 +332,7 @@ class StopInfoBreakpoint : public StopInfo {
 
   ExecutionContext exe_ctx(thread_sp->GetStackFrameAtIndex(0));
   Process *process = exe_ctx.GetProcessPtr();
-  if (process->GetModIDRef().IsLastResumeForUserExpression()) {
+  if (process->GetModIDRef().IsRunningExpression()) {
 // If we are in the middle of evaluating an expression, don't run
 // asynchronous breakpoint commands or expressions.  That could
 // lead to infinite recursion if the command or condition re-calls

diff  --git a/lldb/test/API/macosx/objc_exception_recognizer/Makefile 
b/lldb/test/API/macosx/objc_exception_recognizer/Makefile
new file mode 100644
index 0..66119b1b48248
--- /dev/null
+++ b/lldb/test/API/macosx/objc_exception_recognizer/Makefile
@@ -0,0 +1,4 @@
+OBJC_SOURCES := main.m
+LD_EXTRAS := -framework Foundation
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/macosx/objc_exception_recognizer/TestObjCRecognizer.py 
b/lldb/test/API/macosx/objc_exception_recognizer/TestObjCRecognizer.py
new file mode 100644
index 0..d7e5eb310a191
--- /dev/null
+++ b/lldb/test/API/macosx/objc_exception_recognizer/TestObjCRecognizer.py
@@ -0,0 +1,69 @@
+"""
+Test that the built in ObjC exception throw recognizer works
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+class TestObjCRecognizer(TestBase):
+
+NO_DEBUG_INFO_TESTCASE = True
+
+@skipUnlessDarwin
+def test_exception_recognizer_sub_class(self):
+"""There can be many tests in a test case - describe this test here."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.m")
+self.objc_recognizer_test(True)
+
+@skipUnlessDarwin
+def test_exception_recognizer_plain(self):
+"""There can be many tests in a test case - describe this test here."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.m")
+self.objc_recognizer_test(False)
+
+def objc_recognizer_test(self, sub_class):
+"""Make sure we stop at the exception and get all the fields out of 
the recognizer.
+   If sub_class is True, we make a subclass of NSException and throw 
that."""
+if sub_class:
+bkpt_string = "Set a breakpoint here for MyException"
+else:
+bkpt_string = "Set a breakpoint here for plain exception"
+
+(target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+   bkpt_string, self.main_source_file)
+
+# Now turn on the ObjC Exception breakpoint and continue to hit 

[Lldb-commits] [lldb] 0999996 - Don't expect what newlines look like - never works on Windows.

2023-03-24 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-03-24T12:28:16-07:00
New Revision: 096f68186183eaf065e4a05a3e73170a19ae

URL: 
https://github.com/llvm/llvm-project/commit/096f68186183eaf065e4a05a3e73170a19ae
DIFF: 
https://github.com/llvm/llvm-project/commit/096f68186183eaf065e4a05a3e73170a19ae.diff

LOG: Don't expect what newlines look like - never works on Windows.

Added: 


Modified: 
lldb/test/API/commands/command/backticks/TestBackticksInAlias.py

Removed: 




diff  --git a/lldb/test/API/commands/command/backticks/TestBackticksInAlias.py 
b/lldb/test/API/commands/command/backticks/TestBackticksInAlias.py
index 4a95cff21e713..74c33c66cdd08 100644
--- a/lldb/test/API/commands/command/backticks/TestBackticksInAlias.py
+++ b/lldb/test/API/commands/command/backticks/TestBackticksInAlias.py
@@ -76,6 +76,7 @@ def test_backticks_in_raw_cmd(self):
 interp = self.dbg.GetCommandInterpreter()
 interp.HandleCommand(f"script {argc_value} - `argc`", result)
 self.assertTrue(result.Succeeded(), "Command succeeded")
-self.assertEqual("0\n", result.GetOutput(), "Substitution worked")
+fixed_output = result.GetOutput().rstrip()
+self.assertEqual("0", fixed_output, "Substitution worked")
 
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 75ca15f - Fix backtick handling in parsed commands.

2023-03-24 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-03-24T10:40:10-07:00
New Revision: 75ca15fcbb2e1b3671e41f971a000c6d59f5e5ae

URL: 
https://github.com/llvm/llvm-project/commit/75ca15fcbb2e1b3671e41f971a000c6d59f5e5ae
DIFF: 
https://github.com/llvm/llvm-project/commit/75ca15fcbb2e1b3671e41f971a000c6d59f5e5ae.diff

LOG: Fix backtick handling in parsed commands.

https://reviews.llvm.org/D146779

Added: 


Modified: 
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Interpreter/CommandObject.cpp
lldb/test/API/commands/command/backticks/TestBackticksInAlias.py

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index cf44412b13026..e428614fbedb1 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -637,6 +637,9 @@ class CommandInterpreter : public Broadcaster,
 
   bool IOHandlerInterrupt(IOHandler _handler) override;
 
+  Status PreprocessCommand(std::string );
+  Status PreprocessToken(std::string );
+
 protected:
   friend class Debugger;
 
@@ -671,8 +674,6 @@ class CommandInterpreter : public Broadcaster,
 
   void RestoreExecutionContext();
 
-  Status PreprocessCommand(std::string );
-
   void SourceInitFile(FileSpec file, CommandReturnObject );
 
   // Completely resolves aliases and abbreviations, returning a pointer to the

diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index cf3fff23005bf..09fc8e216bc00 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -1750,112 +1750,124 @@ Status 
CommandInterpreter::PreprocessCommand(std::string ) {
 
 std::string expr_str(command, expr_content_start,
  end_backtick - expr_content_start);
+error = PreprocessToken(expr_str);
+// We always stop at the first error:
+if (error.Fail())
+  break;
 
-ExecutionContext exe_ctx(GetExecutionContext());
+command.erase(start_backtick, end_backtick - start_backtick + 1);
+command.insert(start_backtick, std::string(expr_str));
+pos = start_backtick + expr_str.size();
+  }
+  return error;
+}
 
-// Get a dummy target to allow for calculator mode while processing
-// backticks. This also helps break the infinite loop caused when target is
-// null.
-Target *exe_target = exe_ctx.GetTargetPtr();
-Target  = exe_target ? *exe_target : m_debugger.GetDummyTarget();
-
-ValueObjectSP expr_result_valobj_sp;
-
-EvaluateExpressionOptions options;
-options.SetCoerceToId(false);
-options.SetUnwindOnError(true);
-options.SetIgnoreBreakpoints(true);
-options.SetKeepInMemory(false);
-options.SetTryAllThreads(true);
-options.SetTimeout(std::nullopt);
-
-ExpressionResults expr_result =
-target.EvaluateExpression(expr_str.c_str(), exe_ctx.GetFramePtr(),
-  expr_result_valobj_sp, options);
-
-if (expr_result == eExpressionCompleted) {
-  Scalar scalar;
-  if (expr_result_valobj_sp)
-expr_result_valobj_sp =
-expr_result_valobj_sp->GetQualifiedRepresentationIfAvailable(
-expr_result_valobj_sp->GetDynamicValueType(), true);
-  if (expr_result_valobj_sp->ResolveValue(scalar)) {
-command.erase(start_backtick, end_backtick - start_backtick + 1);
-StreamString value_strm;
-const bool show_type = false;
-scalar.GetValue(_strm, show_type);
-size_t value_string_size = value_strm.GetSize();
-if (value_string_size) {
-  command.insert(start_backtick, std::string(value_strm.GetString()));
-  pos = start_backtick + value_string_size;
-  continue;
-} else {
-  error.SetErrorStringWithFormat("expression value didn't result "
- "in a scalar value for the "
- "expression '%s'",
- expr_str.c_str());
-  break;
-}
-  } else {
-error.SetErrorStringWithFormat("expression value didn't result "
-   "in a scalar value for the "
-   "expression '%s'",
-   expr_str.c_str());
-break;
-  }
+Status
+CommandInterpreter::PreprocessToken(std::string _str) {
+  Status error;
+  ExecutionContext exe_ctx(GetExecutionContext());
 
-  continue;
-}
+  // Get a dummy target to allow for calculator mode while processing
+  // backticks. This also helps break the infinite loop caused when target is
+  // null.
+  Target *exe_target = exe_ctx.GetTargetPtr();
+  Target  = exe_target ? 

Re: [Lldb-commits] [PATCH] D146553: [lldb][CMake] Enforce not linking against plugin libs in core libs

2023-03-22 Thread Jim Ingham via lldb-commits
That general facility is why we think of plugins as something more than just 
implementations.  Along with the "on load" actions, they also have the job of 
detecting "Am I the right implementation for this binary, this language, this 
OS version, etc".   That also informs the proper way to use them.  You start 
with something of a particular plugin type you want to work with - a path to a 
binary or a the language type you got from a StackFrame - which is managed by a 
particular plugin class, and you first ask the manager for that plugin type 
"find me the plugin that handles my entity", then call the generic API's on 
that plugin.  You shouldn't dial up particular plugins or call anything but the 
plugin interface methods on them.  If you have to do something that's specific 
to a particular plugin implementation, that needs to be done inside the plugin, 
and vended in some neutral way.

Jim

> On Mar 22, 2023, at 11:33 AM, Jim Ingham via lldb-commits 
>  wrote:
> 
> David,
> 
> I think you were also thinking about things like the `language cplusplus` 
> commands or the `settings set plugin.***` settings.  That isn't a case of 
> generic code depending on specific plugin implementations.  Rather that's a 
> general feature of the plugin loader, it queries the plugin to see if it has 
> any commands or settings to add to the command interpreter when loaded.  But 
> the command interpreter doesn't "depend" on these plugin commands, it just 
> vends them.
> 
> Jim
> 
>> On Mar 22, 2023, at 10:26 AM, Alex Langford via Phabricator via lldb-commits 
>>  wrote:
>> 
>> bulbazord added a comment.
>> 
>> In D146553#4212417 <https://reviews.llvm.org/D146553#4212417>, 
>> @DavidSpickett wrote:
>> 
>>> Is this policy documented anywhere? Perhaps you can update one of the 
>>> design pages if it isn't already there.
>>> 
>>> Because I am a bit confused about it. Some parts of lldb use plugins and 
>>> those parts are called by commands through a few other layers. However 
>>> commands can't link to the plugins directly, but some of them do show 
>>> information that further down came from a plugin. I'm wondering what the 
>>> best practices are (and some examples would be great!).
>> 
>> This policy is not really documented anywhere. I've been working towards 
>> making the non-plugins not depend on any plugins for a few years now (along 
>> with some other folks, some of whom are no longer working on LLDB). As for 
>> updating one of the design pages, I think I'll update this one: 
>> https://lldb.llvm.org/design/overview.html
>> Currently, we are down to maybe 3-4 places where we're using plugins in 
>> non-plugin contexts and I have a few plans to remove those dependencies. 
>> They're a bit challenging to remove so I'll be moving a bit more carefully.
>> 
>> I can understand the confusion. Navigating LLDB's design is quite 
>> challenging because a lot of it is kind of ad-hoc and grew organically while 
>> some transitions from one thing to another weren't always completed 100%. I 
>> personally think that the name "plugin" is a bit misleading because they're 
>> not really things you can add/remove at runtime. You can't really even 
>> add/remove them at CMake configure time (though there was some interest in 
>> doing this in the past). I think a name better than "plugin" would be 
>> "implementation" because that's what the plugins are: specific 
>> implementations of more general debugger concepts (e.g. ABI support, 
>> Platforms, Languages and LanguageRuntimes, ObjectFiles, etc).
>> 
>> As for best practices, I suppose that depends on exactly which plugin you're 
>> using. If the goal is just to get some information from a relevant plugin, 
>> you can look at the way the Language plugins are designed. The Language 
>> class in `lldb/source/Target/` has several functions like "FindPlugin" and 
>> "ForEach" which let you find the correct plugin for a language and operate 
>> over all known language plugins respectively. A slightly different model 
>> might be how the TypeSystems work. To get a scratch TypeSystem for example, 
>> we usually go through the `Target` that we have with 
>> `Target::GetScratchTypeSystemForLanguage` or something to this effect. I 
>> suppose it just depends on what you're trying to do, which I realize may not 
>> be the most helpful advice but I hope that with enough examples it becomes 
>> at least a little more clear how things in lldb are currently done...
>> 
>> One thing you may notice as you use and extend t

Re: [Lldb-commits] [PATCH] D146553: [lldb][CMake] Enforce not linking against plugin libs in core libs

2023-03-22 Thread Jim Ingham via lldb-commits
David,

I think you were also thinking about things like the `language cplusplus` 
commands or the `settings set plugin.***` settings.  That isn't a case of 
generic code depending on specific plugin implementations.  Rather that's a 
general feature of the plugin loader, it queries the plugin to see if it has 
any commands or settings to add to the command interpreter when loaded.  But 
the command interpreter doesn't "depend" on these plugin commands, it just 
vends them.

Jim
 
> On Mar 22, 2023, at 10:26 AM, Alex Langford via Phabricator via lldb-commits 
>  wrote:
> 
> bulbazord added a comment.
> 
> In D146553#4212417 , @DavidSpickett 
> wrote:
> 
>> Is this policy documented anywhere? Perhaps you can update one of the design 
>> pages if it isn't already there.
>> 
>> Because I am a bit confused about it. Some parts of lldb use plugins and 
>> those parts are called by commands through a few other layers. However 
>> commands can't link to the plugins directly, but some of them do show 
>> information that further down came from a plugin. I'm wondering what the 
>> best practices are (and some examples would be great!).
> 
> This policy is not really documented anywhere. I've been working towards 
> making the non-plugins not depend on any plugins for a few years now (along 
> with some other folks, some of whom are no longer working on LLDB). As for 
> updating one of the design pages, I think I'll update this one: 
> https://lldb.llvm.org/design/overview.html
> Currently, we are down to maybe 3-4 places where we're using plugins in 
> non-plugin contexts and I have a few plans to remove those dependencies. 
> They're a bit challenging to remove so I'll be moving a bit more carefully.
> 
> I can understand the confusion. Navigating LLDB's design is quite challenging 
> because a lot of it is kind of ad-hoc and grew organically while some 
> transitions from one thing to another weren't always completed 100%. I 
> personally think that the name "plugin" is a bit misleading because they're 
> not really things you can add/remove at runtime. You can't really even 
> add/remove them at CMake configure time (though there was some interest in 
> doing this in the past). I think a name better than "plugin" would be 
> "implementation" because that's what the plugins are: specific 
> implementations of more general debugger concepts (e.g. ABI support, 
> Platforms, Languages and LanguageRuntimes, ObjectFiles, etc).
> 
> As for best practices, I suppose that depends on exactly which plugin you're 
> using. If the goal is just to get some information from a relevant plugin, 
> you can look at the way the Language plugins are designed. The Language class 
> in `lldb/source/Target/` has several functions like "FindPlugin" and 
> "ForEach" which let you find the correct plugin for a language and operate 
> over all known language plugins respectively. A slightly different model 
> might be how the TypeSystems work. To get a scratch TypeSystem for example, 
> we usually go through the `Target` that we have with 
> `Target::GetScratchTypeSystemForLanguage` or something to this effect. I 
> suppose it just depends on what you're trying to do, which I realize may not 
> be the most helpful advice but I hope that with enough examples it becomes at 
> least a little more clear how things in lldb are currently done...
> 
> One thing you may notice as you use and extend these plugins is that the base 
> class for the plugin you're working with may not be able to support your use 
> case. In this case, it may make sense to extend the interface to support your 
> use case. The existing interfaces (e.g. TypeSystem) only support what has 
> needed to be done up until now, so there may be a use case that makes sense 
> that nobody bothered to add before. In other cases, it may make sense to rely 
> on specific implementation details in said plugins. Ideally we would not be 
> doing that in non-plugins as those are supposed to be more general though and 
> maybe we can figure out a way to do it in a plugin instead.
> 
> This is all very off the cuff. I hope it makes sense and helps. I will be 
> updating the design document (and I'll add you as a reviewer).
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D146553/new/
> 
> https://reviews.llvm.org/D146553
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] c1e4a0d - Follow on to 2c7abc83f605b2d3b1062f28422eeff81278ecd5.

2023-03-20 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-03-20T16:49:05-07:00
New Revision: c1e4a0d4dbe9d68113a877764c794407bdd65622

URL: 
https://github.com/llvm/llvm-project/commit/c1e4a0d4dbe9d68113a877764c794407bdd65622
DIFF: 
https://github.com/llvm/llvm-project/commit/c1e4a0d4dbe9d68113a877764c794407bdd65622.diff

LOG: Follow on to 2c7abc83f605b2d3b1062f28422eeff81278ecd5.

I didn't refactor the test that's failing on arm64 correctly so it
failed everywhere.

Looks like the step test passes on other aarch64 systems as well as
Darwin.  Turn off the xfail and see how far that gets.

Added: 


Modified: 

lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py

Removed: 




diff  --git 
a/lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
 
b/lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
index 52fc899b13e61..fd70bd692a216 100644
--- 
a/lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
+++ 
b/lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
@@ -36,12 +36,6 @@ def get_to_start(self, bkpt_text):
 
 return (target, process, thread, read_watchpoint)
 
-@expectedFailureAll(
-oslist=["freebsd", "linux"],
-archs=[
-'aarch64',
-'arm'],
-bugnumber="llvm.org/pr26031")
 # Read-write watchpoints not supported on SystemZ
 @expectedFailureAll(archs=['s390x'])
 @add_test_categories(["basic_process"])
@@ -69,8 +63,6 @@ def test_step_over(self):
 def test_step_instruction(self):
 target, process, thread, wp = self.get_to_start("Set breakpoint after 
call")
 
-self.assertEquals(thread.GetStopDescription(20), 'step over')
-
 self.step_inst_for_watchpoint(1)
 
 write_value = frame.FindValue('g_watch_me_write',



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 2c7abc8 - Reapply 8d024a79ea783ed3fbb5691aeaf186ad3f0a4ae9 w/o the extra bits.

2023-03-20 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-03-20T16:11:00-07:00
New Revision: 2c7abc83f605b2d3b1062f28422eeff81278ecd5

URL: 
https://github.com/llvm/llvm-project/commit/2c7abc83f605b2d3b1062f28422eeff81278ecd5
DIFF: 
https://github.com/llvm/llvm-project/commit/2c7abc83f605b2d3b1062f28422eeff81278ecd5.diff

LOG: Reapply 8d024a79ea783ed3fbb5691aeaf186ad3f0a4ae9 w/o the extra bits.

Added: 


Modified: 
lldb/source/Target/StopInfo.cpp

lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
lldb/test/API/commands/watchpoints/step_over_watchpoint/main.c

Removed: 




diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index 9fdb29f9e4273..ebc355c90d0ab 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -831,6 +831,11 @@ class StopInfoWatchpoint : public StopInfo {
   = std::static_pointer_cast(shared_from_this());
   ThreadPlanSP step_over_wp_sp(new ThreadPlanStepOverWatchpoint(
   *(thread_sp.get()), me_as_siwp_sp, wp_sp));
+  // When this plan is done we want to stop, so set this as a Controlling
+  // plan.
+  step_over_wp_sp->SetIsControllingPlan(true);
+  step_over_wp_sp->SetOkayToDiscard(false);
+
   Status error;
   error = thread_sp->QueueThreadPlan(step_over_wp_sp, false);
   // If we couldn't push the thread plan, just stop here:

diff  --git 
a/lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
 
b/lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
index 7d54156aebb5b..52fc899b13e61 100644
--- 
a/lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
+++ 
b/lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
@@ -11,36 +11,11 @@
 class TestStepOverWatchpoint(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
-@expectedFailureAll(
-oslist=["freebsd", "linux"],
-archs=[
-'aarch64',
-'arm'],
-bugnumber="llvm.org/pr26031")
-# Read-write watchpoints not supported on SystemZ
-@expectedFailureAll(archs=['s390x'])
-@expectedFailureAll(
-oslist=["ios", "watchos", "tvos", "bridgeos", "macosx"],
-archs=['aarch64', 'arm'],
-bugnumber="")
-@add_test_categories(["basic_process"])
-def test(self):
+def get_to_start(self, bkpt_text):
 """Test stepping over watchpoints."""
 self.build()
-target = self.createTestTarget()
-
-lldbutil.run_break_set_by_symbol(self, 'main')
-
-process = target.LaunchSimple(None, None,
-  self.get_process_working_directory())
-self.assertTrue(process.IsValid(), PROCESS_IS_VALID)
-self.assertState(process.GetState(), lldb.eStateStopped,
- PROCESS_STOPPED)
-
-thread = lldbutil.get_stopped_thread(process,
- lldb.eStopReasonBreakpoint)
-self.assertTrue(thread.IsValid(), "Failed to get thread.")
-
+target, process, thread, bkpt = 
lldbutil.run_to_source_breakpoint(self, bkpt_text,
+   
lldb.SBFileSpec("main.c"))
 frame = thread.GetFrameAtIndex(0)
 self.assertTrue(frame.IsValid(), "Failed to get frame.")
 
@@ -55,14 +30,45 @@ def test(self):
 self.assertSuccess(error, "Error while setting watchpoint")
 self.assertTrue(read_watchpoint, "Failed to set read watchpoint.")
 
+# Disable the breakpoint we hit so we don't muddy the waters with
+# stepping off from the breakpoint:
+bkpt.SetEnabled(False)
+
+return (target, process, thread, read_watchpoint)
+
+@expectedFailureAll(
+oslist=["freebsd", "linux"],
+archs=[
+'aarch64',
+'arm'],
+bugnumber="llvm.org/pr26031")
+# Read-write watchpoints not supported on SystemZ
+@expectedFailureAll(archs=['s390x'])
+@add_test_categories(["basic_process"])
+def test_step_over(self):
+target, process, thread, wp = self.get_to_start("Set a breakpoint 
here")
+
 thread.StepOver()
 self.assertStopReason(thread.GetStopReason(), 
lldb.eStopReasonWatchpoint,
 STOPPED_DUE_TO_WATCHPOINT)
 self.assertEquals(thread.GetStopDescription(20), 'watchpoint 1')
 
-process.Continue()
-self.assertState(process.GetState(), lldb.eStateStopped,
- PROCESS_STOPPED)
+@expectedFailureAll(
+oslist=["freebsd", "linux"],
+archs=[
+'aarch64',
+'arm'],
+bugnumber="llvm.org/pr26031")
+# Read-write watchpoints not supported on SystemZ
+@expectedFailureAll(archs=['s390x'])
+@expectedFailureAll(
+

[Lldb-commits] [lldb] 9b655c2 - Revert "Fix a problem with "watchpoint triggers before" watchpoint handling."

2023-03-20 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-03-20T16:05:57-07:00
New Revision: 9b655c2627e31ea62032e175b3a9f2cae8aea653

URL: 
https://github.com/llvm/llvm-project/commit/9b655c2627e31ea62032e175b3a9f2cae8aea653
DIFF: 
https://github.com/llvm/llvm-project/commit/9b655c2627e31ea62032e175b3a9f2cae8aea653.diff

LOG: Revert "Fix a problem with "watchpoint triggers before" watchpoint 
handling."

This reverts commit 8d024a79ea783ed3fbb5691aeaf186ad3f0a4ae9.

I accidentally included some "in progress" work that wasn't supposed to
go with this commit.

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
lldb/source/Target/StopInfo.cpp
lldb/source/Target/Thread.cpp

lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
lldb/test/API/commands/watchpoints/step_over_watchpoint/main.c

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 6ce38f63cd249..3ffacb52299b9 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -311,14 +311,6 @@ class ProcessModID {
   return m_last_natural_stop_event;
 return lldb::EventSP();
   }
-  
-  void SetSafeToCallFunctions(bool safe) {
-m_safe = safe;
-  }
-  
-  bool GetSafeToCallFunctions() {
-return m_safe;
-  }
 
 private:
   uint32_t m_stop_id = 0;
@@ -329,7 +321,6 @@ class ProcessModID {
   uint32_t m_running_user_expression = false;
   uint32_t m_running_utility_function = 0;
   lldb::EventSP m_last_natural_stop_event;
-  std::atomic m_safe = true;
 };
 
 inline bool operator==(const ProcessModID , const ProcessModID ) {
@@ -468,7 +459,7 @@ class Process : public 
std::enable_shared_from_this,
 void SetRestarted(bool new_value) { m_restarted = new_value; }
 
 void SetInterrupted(bool new_value) { m_interrupted = new_value; }
-
+
 void AddRestartedReason(const char *reason) {
   m_restarted_reasons.push_back(reason);
 }
@@ -1259,14 +1250,6 @@ class Process : public 
std::enable_shared_from_this,
 DiagnosticManager _manager);
 
   static const char *ExecutionResultAsCString(lldb::ExpressionResults result);
-  
-  void SetSafeToCallFunctions(bool safe) {
-GetModID().SetSafeToCallFunctions(safe);
-  }
-  
-  bool GetSafeToCallFunctions() {
-return GetModID().GetSafeToCallFunctions();
-  }
 
   void GetStatus(Stream );
 

diff  --git a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp 
b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
index 458d44f6feb33..aae15b2ef4624 100644
--- a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
+++ b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
@@ -795,19 +795,6 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
   case 9:  // EXC_RPC_ALERT
   case 10: // EXC_CRASH
 break;
-  case 12: // EXC_GUARD
-{
-  // Some EXC_GUARD exceptions are fatal, and the process will go away
-  // the next time you allow it to run.  When we get one of those 
-  // exceptions we have to make sure SafeToCallFunctions returns false to
-  // prevent us or other agents running the process.  This has to be set
-  // on the process because even the threads that didn't get the exception
-  // can't run.
-  ProcessSP process_sp(thread.GetProcess());
-  if (process_sp)
-process_sp->SetSafeToCallFunctions(false);
-  
-}
   }
 
   return StopInfoSP(new StopInfoMachException(thread, exc_type, exc_data_count,

diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index ebc355c90d0ab..9fdb29f9e4273 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -831,11 +831,6 @@ class StopInfoWatchpoint : public StopInfo {
   = std::static_pointer_cast(shared_from_this());
   ThreadPlanSP step_over_wp_sp(new ThreadPlanStepOverWatchpoint(
   *(thread_sp.get()), me_as_siwp_sp, wp_sp));
-  // When this plan is done we want to stop, so set this as a Controlling
-  // plan.
-  step_over_wp_sp->SetIsControllingPlan(true);
-  step_over_wp_sp->SetOkayToDiscard(false);
-
   Status error;
   error = thread_sp->QueueThreadPlan(step_over_wp_sp, false);
   // If we couldn't push the thread plan, just stop here:

diff  --git a/lldb/source/Target/Thread.cpp b/lldb/source/Target/Thread.cpp
index df8bff5102b83..d620f746339e7 100644
--- a/lldb/source/Target/Thread.cpp
+++ b/lldb/source/Target/Thread.cpp
@@ -1664,9 +1664,6 @@ addr_t Thread::GetThreadLocalData(const ModuleSP module,
 bool Thread::SafeToCallFunctions() {
   Process *process = GetProcess().get();
   if (process) {
-if (!process->SafeToCallFunctions())
-  return false;
-
 DynamicLoader *loader = GetProcess()->GetDynamicLoader();
 if (loader && 

[Lldb-commits] [lldb] 8d024a7 - Fix a problem with "watchpoint triggers before" watchpoint handling.

2023-03-20 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-03-20T15:17:15-07:00
New Revision: 8d024a79ea783ed3fbb5691aeaf186ad3f0a4ae9

URL: 
https://github.com/llvm/llvm-project/commit/8d024a79ea783ed3fbb5691aeaf186ad3f0a4ae9
DIFF: 
https://github.com/llvm/llvm-project/commit/8d024a79ea783ed3fbb5691aeaf186ad3f0a4ae9.diff

LOG: Fix a problem with "watchpoint triggers before" watchpoint handling.

We need to step the watchpoint instruction in these cases, but the
when we queued the ThreadPlanStepOverWatchpoint to do this, we didn't
make it a Controlling plan.  So if you are stepping, this plan returns as
though it were a utility plan, and the stepping plan keeps going.

This only partially fixes the problem on Darwin; there's another bug
with reporting a watchpoint when we're instruction single stepping over
an instruction that triggers a watchpoint.  The kernel reports the
"single step completed" but not the watchpoint hit.  So this commit
also refactors the test into a part that works (at least on Darwin) and
a part that still fails.

We may have to adjust the test result expectations for other systems after
this fix.

Differential Revision: https://reviews.llvm.org/D146337

Added: 


Modified: 
lldb/include/lldb/Target/Process.h
lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
lldb/source/Target/StopInfo.cpp
lldb/source/Target/Thread.cpp

lldb/test/API/commands/watchpoints/step_over_watchpoint/TestStepOverWatchpoint.py
lldb/test/API/commands/watchpoints/step_over_watchpoint/main.c

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 3ffacb52299b9..6ce38f63cd249 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -311,6 +311,14 @@ class ProcessModID {
   return m_last_natural_stop_event;
 return lldb::EventSP();
   }
+  
+  void SetSafeToCallFunctions(bool safe) {
+m_safe = safe;
+  }
+  
+  bool GetSafeToCallFunctions() {
+return m_safe;
+  }
 
 private:
   uint32_t m_stop_id = 0;
@@ -321,6 +329,7 @@ class ProcessModID {
   uint32_t m_running_user_expression = false;
   uint32_t m_running_utility_function = 0;
   lldb::EventSP m_last_natural_stop_event;
+  std::atomic m_safe = true;
 };
 
 inline bool operator==(const ProcessModID , const ProcessModID ) {
@@ -459,7 +468,7 @@ class Process : public 
std::enable_shared_from_this,
 void SetRestarted(bool new_value) { m_restarted = new_value; }
 
 void SetInterrupted(bool new_value) { m_interrupted = new_value; }
-
+
 void AddRestartedReason(const char *reason) {
   m_restarted_reasons.push_back(reason);
 }
@@ -1250,6 +1259,14 @@ class Process : public 
std::enable_shared_from_this,
 DiagnosticManager _manager);
 
   static const char *ExecutionResultAsCString(lldb::ExpressionResults result);
+  
+  void SetSafeToCallFunctions(bool safe) {
+GetModID().SetSafeToCallFunctions(safe);
+  }
+  
+  bool GetSafeToCallFunctions() {
+return GetModID().GetSafeToCallFunctions();
+  }
 
   void GetStatus(Stream );
 

diff  --git a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp 
b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
index aae15b2ef4624..458d44f6feb33 100644
--- a/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
+++ b/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp
@@ -795,6 +795,19 @@ StopInfoSP 
StopInfoMachException::CreateStopReasonWithMachException(
   case 9:  // EXC_RPC_ALERT
   case 10: // EXC_CRASH
 break;
+  case 12: // EXC_GUARD
+{
+  // Some EXC_GUARD exceptions are fatal, and the process will go away
+  // the next time you allow it to run.  When we get one of those 
+  // exceptions we have to make sure SafeToCallFunctions returns false to
+  // prevent us or other agents running the process.  This has to be set
+  // on the process because even the threads that didn't get the exception
+  // can't run.
+  ProcessSP process_sp(thread.GetProcess());
+  if (process_sp)
+process_sp->SetSafeToCallFunctions(false);
+  
+}
   }
 
   return StopInfoSP(new StopInfoMachException(thread, exc_type, exc_data_count,

diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index 9fdb29f9e4273..ebc355c90d0ab 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -831,6 +831,11 @@ class StopInfoWatchpoint : public StopInfo {
   = std::static_pointer_cast(shared_from_this());
   ThreadPlanSP step_over_wp_sp(new ThreadPlanStepOverWatchpoint(
   *(thread_sp.get()), me_as_siwp_sp, wp_sp));
+  // When this plan is done we want to stop, so set this as a Controlling
+  // plan.
+  step_over_wp_sp->SetIsControllingPlan(true);
+  step_over_wp_sp->SetOkayToDiscard(false);
+
   Status error;
   error = 

[Lldb-commits] [lldb] fe61b38 - Add a Debugger interruption mechanism in conjunction with the

2023-03-15 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-03-15T16:45:14-07:00
New Revision: fe61b38258bf4c5f34c32de26f4ed11ef5c32ebc

URL: 
https://github.com/llvm/llvm-project/commit/fe61b38258bf4c5f34c32de26f4ed11ef5c32ebc
DIFF: 
https://github.com/llvm/llvm-project/commit/fe61b38258bf4c5f34c32de26f4ed11ef5c32ebc.diff

LOG: Add a Debugger interruption mechanism in conjunction with the
Command Interpreter mechanism.

Differential Revision: https://reviews.llvm.org/D145136

Added: 
lldb/test/API/python_api/was_interrupted/Makefile
lldb/test/API/python_api/was_interrupted/TestDebuggerInterruption.py
lldb/test/API/python_api/was_interrupted/interruptible.py
lldb/test/API/python_api/was_interrupted/main.c

Modified: 
lldb/include/lldb/API/SBCommandInterpreter.h
lldb/include/lldb/API/SBDebugger.h
lldb/include/lldb/Core/Debugger.h
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/source/API/SBCommandInterpreter.cpp
lldb/source/API/SBDebugger.cpp
lldb/source/API/SBFrame.cpp
lldb/source/Commands/CommandObjectTarget.cpp
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Core/Debugger.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Target/StackFrameList.cpp

Removed: 




diff  --git a/lldb/include/lldb/API/SBCommandInterpreter.h 
b/lldb/include/lldb/API/SBCommandInterpreter.h
index 08ed989714d13..7c3f8275471e8 100644
--- a/lldb/include/lldb/API/SBCommandInterpreter.h
+++ b/lldb/include/lldb/API/SBCommandInterpreter.h
@@ -241,7 +241,20 @@ class SBCommandInterpreter {
lldb::SBStringList ,
lldb::SBStringList );
 
+  /// Returns whether an interrupt flag was raised either by the SBDebugger - 
+  /// when the function is not running on the RunCommandInterpreter thread, or
+  /// by SBCommandInterpreter::InterruptCommand if it is.  If your code is 
doing
+  /// interruptible work, check this API periodically, and interrupt if it 
+  /// returns true.
   bool WasInterrupted() const;
+  
+  /// Interrupts the command currently executing in the RunCommandInterpreter
+  /// thread.
+  ///
+  /// \return
+  ///   \b true if there was a command in progress to recieve the interrupt.
+  ///   \b false if there's no command currently in flight.
+  bool InterruptCommand();
 
   // Catch commands before they execute by registering a callback that will get
   // called when the command gets executed. This allows GUI or command line

diff  --git a/lldb/include/lldb/API/SBDebugger.h 
b/lldb/include/lldb/API/SBDebugger.h
index 8e8e1b61e08fb..bdcd5eeaaffdb 100644
--- a/lldb/include/lldb/API/SBDebugger.h
+++ b/lldb/include/lldb/API/SBDebugger.h
@@ -197,6 +197,10 @@ class LLDB_API SBDebugger {
   lldb::SBCommandInterpreter GetCommandInterpreter();
 
   void HandleCommand(const char *command);
+  
+  void RequestInterrupt();
+  void CancelInterruptRequest();
+  bool InterruptRequested();
 
   lldb::SBListener GetListener();
 

diff  --git a/lldb/include/lldb/Core/Debugger.h 
b/lldb/include/lldb/Core/Debugger.h
index 3d2a37871d794..1d9d691bc2b06 100644
--- a/lldb/include/lldb/Core/Debugger.h
+++ b/lldb/include/lldb/Core/Debugger.h
@@ -371,6 +371,48 @@ class Debugger : public 
std::enable_shared_from_this,
   bool IsHandlingEvents() const { return m_event_handler_thread.IsJoinable(); }
 
   Status RunREPL(lldb::LanguageType language, const char *repl_options);
+  
+  /// Interruption in LLDB:
+  /// 
+  /// This is a voluntary interruption mechanism, not preemptive.  Parts of 
lldb
+  /// that do work that can be safely interrupted call 
+  /// Debugger::InterruptRequested and if that returns true, they should return
+  /// at a safe point, shortcutting the rest of the work they were to do.
+  ///  
+  /// lldb clients can both offer a CommandInterpreter (through 
+  /// RunCommandInterpreter) and use the SB API's for their own purposes, so it
+  /// is convenient to separate "interrupting the CommandInterpreter execution"
+  /// and interrupting the work it is doing with the SB API's.  So there are 
two 
+  /// ways to cause an interrupt: 
+  ///   * CommandInterpreter::InterruptCommand: Interrupts the command 
currently
+  /// running in the command interpreter IOHandler thread
+  ///   * Debugger::RequestInterrupt: Interrupts are active on anything but the
+  /// CommandInterpreter thread till CancelInterruptRequest is called.
+  ///
+  /// Since the two checks are mutually exclusive, however, it's also 
convenient
+  /// to have just one function to check the interrupt state.
+
+
+  /// Bump the "interrupt requested" count on the debugger to support
+  /// cooperative interruption.  If this is non-zero, InterruptRequested will
+  /// return true.  Interruptible operations are expected to query the
+  /// InterruptRequested API periodically, and interrupt what they were doing
+  /// if it returns \b 

Re: [Lldb-commits] [PATCH] D146058: [lldb][gnustep] Add basic test and infrastructure for GNUstep ObjC runtime

2023-03-14 Thread Jim Ingham via lldb-commits


> On Mar 14, 2023, at 12:10 PM, Stefan Gränitz via Phabricator via lldb-commits 
>  wrote:
> 
> sgraenitz marked 2 inline comments as done.
> sgraenitz added a comment.
> 
> Soo, @DavidSpickett
> 
> In D146058#4193446 , @DavidSpickett 
> wrote:
> 
>> I am not familiar with Objective C, especially beyond Apple platforms. Are 
>> you aiming to run all the existing Objective C test cases with this 
>> different runtime or will it be mainly new tests?
>> (would be very neat if you got all the existing stuff for free)
> 
> It would be great to get all the existing Objective C test coverage for free, 
> but I guess it'd take a while to support all of the Apple runtime features. 
> Literally all existing ObjC tests are API tests and when running locally, 
> they are all `UNSUPPORTED` for me on Linux and Windows. I didn't manage to 
> get them running quickly and thus, I went for a Shell test here. My 
> impression was that API tests are LLDB legacy and new tests would usually be 
> Shell. It might still be worth getting (some of) the API tests to work with 
> GNUstep as well, but I might need some advice on how to do that.

That is not true.  The shell tests are generally less accurate than the API 
tests - it's much easier to make a test that isn't doing what you thought 
because they match something unintended.  If the test goes wrong, they are also 
harder to debug.  We use them for things where you really do want the terminal 
type interaction or where they are testing very simple stuff.  For anything 
more complicated than that, the API tests are generally a better way to go, and 
if you're on the fence, I at least always suggest API tests.

Jim


> 
> In D146058#4193470 , @DavidSpickett 
> wrote:
> 
>> Myself and Omair both work on Linaro's bots. We run lldb checks on linux 
>> arm/aarch64 and Windows on Arm. We could look at installing it.
> 
> I suspect `lldb-arm-ubuntu` means 32-bit ARM. This should work, but it's not 
> a priority for us right now. We could still give it a try and see if it works 
> out-of-the-box!
> 
> As a side-note: Could the AArch64 bot 
> https://lab.llvm.org/buildbot/#/builders/219 pass `LLVM_LIT_ARGS="-v"` as 
> well so the log tells us which tests actually ran? That would be great!
> 
> 
> 
> 
> Comment at: lldb/test/CMakeLists.txt:32
> +  set(gnustep_info lib/libobjc.so)
> +elseif (WIN32 AND EXISTS "C:/Program Files (x86)/libobjc/lib/objc.dll"
> +  AND EXISTS "C:/Program Files 
> (x86)/libobjc/include/objc/runtime.h")
> 
> DavidSpickett wrote:
>> Does this library work on Windows on Arm (AArch64 Windows)?
>> 
>> Fine not to handle that in this change, just curious. We (Linaro) do have an 
>> lldb bot for it, so it could be added at some point.
> Not yet: https://github.com/gnustep/libobjc2/issues/227
> 
> 
> 
> Comment at: lldb/test/Shell/lit.cfg.py:27
> # by individual lit.local.cfg files in the test subdirectories.
> -config.suffixes = ['.test', '.cpp', '.s']
> +config.suffixes = ['.test', '.cpp', '.s', '.m']
> 
> 
> sgraenitz wrote:
>> DavidSpickett wrote:
>>> There are a couple of .m files in the Shell dir already, I assume the 
>>> related tests still pass for those?
>> Interesting, it's exactly one .m and one .mm outside `Input` directories 
>> right? Let me double-check that.
>> ```
>> SymbolFile/DWARF/clang-ast-from-dwarf-objc-property.m
>> SymbolFile/DWARF/x86/module-ownership.mm
>> ```
> These have been running ever since, because 
> https://github.com/llvm/llvm-project/blob/release/16.x/lldb/test/Shell/SymbolFile/DWARF/lit.local.cfg
>  Anyway, thanks for your note!
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D146058/new/
> 
> https://reviews.llvm.org/D146058
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] e1462d1 - Don't produce a dynamic value if there was an error creating it.

2023-03-10 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-03-10T10:21:50-08:00
New Revision: e1462d14b1e4be329a95bdd08181b97a7a3ad6e6

URL: 
https://github.com/llvm/llvm-project/commit/e1462d14b1e4be329a95bdd08181b97a7a3ad6e6
DIFF: 
https://github.com/llvm/llvm-project/commit/e1462d14b1e4be329a95bdd08181b97a7a3ad6e6.diff

LOG: Don't produce a dynamic value if there was an error creating it.

We used to make a dynamic value that "pretended to be its parent"
but that's hard for some of the more complex ValueObject types, and
it's better in this case just to return no dynamic value.

Differential Revision: https://reviews.llvm.org/D145629

Added: 
lldb/test/API/python_api/value/addr_of_void_star/Makefile

lldb/test/API/python_api/value/addr_of_void_star/TestValueAPIAddressOfVoidStar.py
lldb/test/API/python_api/value/addr_of_void_star/main.c

Modified: 
lldb/source/Core/ValueObject.cpp
lldb/source/Core/ValueObjectConstResult.cpp
lldb/source/Core/ValueObjectDynamicValue.cpp

lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp

Removed: 




diff  --git a/lldb/source/Core/ValueObject.cpp 
b/lldb/source/Core/ValueObject.cpp
index 6e79a04d024e5..1be7e2c322f0d 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -1859,7 +1859,7 @@ ValueObjectSP 
ValueObject::GetDynamicValue(DynamicValueType use_dynamic) {
   if (!IsDynamic() && m_dynamic_value == nullptr) {
 CalculateDynamicValue(use_dynamic);
   }
-  if (m_dynamic_value)
+  if (m_dynamic_value && m_dynamic_value->GetError().Success())
 return m_dynamic_value->GetSP();
   else
 return ValueObjectSP();

diff  --git a/lldb/source/Core/ValueObjectConstResult.cpp 
b/lldb/source/Core/ValueObjectConstResult.cpp
index 640abdddfcad5..17a725dcc7dd8 100644
--- a/lldb/source/Core/ValueObjectConstResult.cpp
+++ b/lldb/source/Core/ValueObjectConstResult.cpp
@@ -287,7 +287,7 @@ 
ValueObjectConstResult::GetDynamicValue(lldb::DynamicValueType use_dynamic) {
   if (process && process->IsPossibleDynamicValue(*this))
 m_dynamic_value = new ValueObjectDynamicValue(*this, use_dynamic);
 }
-if (m_dynamic_value)
+if (m_dynamic_value && m_dynamic_value->GetError().Success())
   return m_dynamic_value->GetSP();
   }
   return ValueObjectSP();

diff  --git a/lldb/source/Core/ValueObjectDynamicValue.cpp 
b/lldb/source/Core/ValueObjectDynamicValue.cpp
index 0659c771918a5..9db50aeeec9ea 100644
--- a/lldb/source/Core/ValueObjectDynamicValue.cpp
+++ b/lldb/source/Core/ValueObjectDynamicValue.cpp
@@ -187,17 +187,19 @@ bool ValueObjectDynamicValue::UpdateValue() {
 m_type_impl.Clear();
   }
 
-  // If we don't have a dynamic type, then make ourselves just a echo of our
-  // parent. Or we could return false, and make ourselves an echo of our
-  // parent?
+  // If we don't have a dynamic type, set ourselves to be invalid and return
+  // false.  We used to try to produce a dynamic ValueObject that behaved 
"like"
+  // its parent, but that failed for ValueObjectConstResult, which is too 
+  // complex a beast to try to emulate.  If we return an invalid ValueObject,
+  // clients will end up getting the static value instead, which behaves
+  // correctly.
   if (!found_dynamic_type) {
 if (m_dynamic_type_info)
   SetValueDidChange(true);
 ClearDynamicTypeInformation();
 m_dynamic_type_info.Clear();
-m_value = m_parent->GetValue();
-m_error = m_value.GetValueAsData(_ctx, m_data, GetModule().get());
-return m_error.Success();
+m_error.SetErrorString("no dynamic type found");
+return false;
   }
 
   Value old_value(m_value);

diff  --git 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
index f05997fa03af8..2879aa64fd7c3 100644
--- 
a/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
+++ 
b/lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
@@ -583,7 +583,11 @@ ValueObjectSP 
ItaniumABILanguageRuntime::GetExceptionObjectForThread(
   ValueObjectSP exception = ValueObject::CreateValueObjectFromData(
   "exception", exception_isw.GetAsData(m_process->GetByteOrder()), exe_ctx,
   voidstar);
-  exception = exception->GetDynamicValue(eDynamicDontRunTarget);
+  ValueObjectSP dyn_exception 
+  = exception->GetDynamicValue(eDynamicDontRunTarget);
+  // If we succeed in making a dynamic value, return that:
+  if (dyn_exception) 
+ return dyn_exception;
 
   return exception;
 }

diff  --git a/lldb/test/API/python_api/value/addr_of_void_star/Makefile 
b/lldb/test/API/python_api/value/addr_of_void_star/Makefile
new file mode 100644
index 0..10495940055b6
--- /dev/null
+++ b/lldb/test/API/python_api/value/addr_of_void_star/Makefile
@@ -0,0 +1,3 @@

[Lldb-commits] [lldb] a92f783 - Fix the run locker setting for async launches that don't stop at the

2023-02-28 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-02-28T17:34:49-08:00
New Revision: a92f7832f35c6c4792d8693e724c19802da75b36

URL: 
https://github.com/llvm/llvm-project/commit/a92f7832f35c6c4792d8693e724c19802da75b36
DIFF: 
https://github.com/llvm/llvm-project/commit/a92f7832f35c6c4792d8693e724c19802da75b36.diff

LOG: Fix the run locker setting for async launches that don't stop at the
initial stop.  The code was using PrivateResume when it should have
used Resume.

This was allowing expression evaluation while the target was running,
and though that was caught a litle later on, we should never have gotten
that far.  To make sure that this is caught immediately I made an error
SBValue when this happens, and test that we get this error.

Differential Revision: https://reviews.llvm.org/D144665

Added: 
lldb/test/API/python_api/run_locker/Makefile
lldb/test/API/python_api/run_locker/TestRunLocker.py
lldb/test/API/python_api/run_locker/main.c

Modified: 
lldb/source/API/SBFrame.cpp
lldb/source/API/SBTarget.cpp
lldb/source/Target/Target.cpp

Removed: 




diff  --git a/lldb/source/API/SBFrame.cpp b/lldb/source/API/SBFrame.cpp
index eb7ec3bbf8d68..bf833fbb95615 100644
--- a/lldb/source/API/SBFrame.cpp
+++ b/lldb/source/API/SBFrame.cpp
@@ -19,6 +19,7 @@
 #include "lldb/Core/StreamFile.h"
 #include "lldb/Core/ValueObjectRegister.h"
 #include "lldb/Core/ValueObjectVariable.h"
+#include "lldb/Core/ValueObjectConstResult.h"
 #include "lldb/Expression/ExpressionVariable.h"
 #include "lldb/Expression/UserExpression.h"
 #include "lldb/Host/Host.h"
@@ -988,6 +989,12 @@ SBValue SBFrame::EvaluateExpression(const char *expr) {
 else
   options.SetLanguage(frame->GetLanguage());
 return EvaluateExpression(expr, options);
+  } else {
+Status error;
+error.SetErrorString("can't evaluate expressions when the "
+   "process is running.");
+ValueObjectSP error_val_sp = ValueObjectConstResult::Create(nullptr, 
error);
+result.SetSP(error_val_sp, false);
   }
   return result;
 }
@@ -1051,7 +1058,6 @@ lldb::SBValue SBFrame::EvaluateExpression(const char 
*expr,
   std::unique_lock lock;
   ExecutionContext exe_ctx(m_opaque_sp.get(), lock);
 
-
   StackFrame *frame = nullptr;
   Target *target = exe_ctx.GetTargetPtr();
   Process *process = exe_ctx.GetProcessPtr();
@@ -1075,13 +1081,30 @@ lldb::SBValue SBFrame::EvaluateExpression(const char 
*expr,
 target->EvaluateExpression(expr, frame, expr_value_sp, options.ref());
 expr_result.SetSP(expr_value_sp, options.GetFetchDynamicValue());
   }
+} else {
+  Status error;
+  error.SetErrorString("can't evaluate expressions when the "
+   "process is running.");
+  expr_value_sp = ValueObjectConstResult::Create(nullptr, error);
+  expr_result.SetSP(expr_value_sp, false);
 }
+  } else {
+  Status error;
+  error.SetErrorString("sbframe object is not valid.");
+  expr_value_sp = ValueObjectConstResult::Create(nullptr, error);
+  expr_result.SetSP(expr_value_sp, false);
   }
 
-  LLDB_LOGF(expr_log,
-"** [SBFrame::EvaluateExpression] Expression result is "
-"%s, summary %s **",
-expr_result.GetValue(), expr_result.GetSummary());
+  if (expr_result.GetError().Success())
+LLDB_LOGF(expr_log,
+  "** [SBFrame::EvaluateExpression] Expression result is "
+  "%s, summary %s **",
+  expr_result.GetValue(), expr_result.GetSummary());
+  else
+LLDB_LOGF(expr_log,
+  "** [SBFrame::EvaluateExpression] Expression evaluation failed: "
+  "%s **",
+  expr_result.GetError().GetCString());
 
   return expr_result;
 }

diff  --git a/lldb/source/API/SBTarget.cpp b/lldb/source/API/SBTarget.cpp
index cadaeb472e289..6e5942904db78 100644
--- a/lldb/source/API/SBTarget.cpp
+++ b/lldb/source/API/SBTarget.cpp
@@ -2219,12 +2219,25 @@ lldb::SBValue SBTarget::EvaluateExpression(const char 
*expr,
 std::lock_guard guard(target_sp->GetAPIMutex());
 ExecutionContext exe_ctx(m_opaque_sp.get());
 
-
 frame = exe_ctx.GetFramePtr();
 Target *target = exe_ctx.GetTargetPtr();
+Process *process = exe_ctx.GetProcessPtr();
 
 if (target) {
-  target->EvaluateExpression(expr, frame, expr_value_sp, options.ref());
+  // If we have a process, make sure to lock the runlock:
+  if (process) {
+Process::StopLocker stop_locker;
+if (stop_locker.TryLock(>GetRunLock())) {
+  target->EvaluateExpression(expr, frame, expr_value_sp, 
options.ref());
+} else {
+  Status error;
+  error.SetErrorString("can't evaluate expressions when the "
+   "process is running.");
+  expr_value_sp = ValueObjectConstResult::Create(nullptr, error);
+}
+  } else {
+

[Lldb-commits] [lldb] 00b2c33 - Fix typos in the test command for D144929

2023-02-28 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-02-28T16:59:19-08:00
New Revision: 00b2c33c9359e1f75dd29d5083fac66bfd52db6e

URL: 
https://github.com/llvm/llvm-project/commit/00b2c33c9359e1f75dd29d5083fac66bfd52db6e
DIFF: 
https://github.com/llvm/llvm-project/commit/00b2c33c9359e1f75dd29d5083fac66bfd52db6e.diff

LOG: Fix typos in the test command for D144929

Added: 


Modified: 
lldb/test/API/commands/command/script/TestCommandScript.py

Removed: 




diff  --git a/lldb/test/API/commands/command/script/TestCommandScript.py 
b/lldb/test/API/commands/command/script/TestCommandScript.py
index b81acef261067..6716f852dcbf0 100644
--- a/lldb/test/API/commands/command/script/TestCommandScript.py
+++ b/lldb/test/API/commands/command/script/TestCommandScript.py
@@ -21,8 +21,8 @@ def pycmd_tests(self):
 
 # Test that we did indeed add these commands as user commands:
 interp = self.dbg.GetCommandInterpreter()
-self.expectTrue(interp.UserCommandExists("foobar"), "foobar exists")
-self.expectFalse(interp.CommandExists("foobar"), "It is not a 
builtin.")
+self.assertTrue(interp.UserCommandExists("foobar"), "foobar exists")
+self.assertFalse(interp.CommandExists("foobar"), "It is not a 
builtin.")
 
 # Test a bunch of 
diff erent kinds of python callables with
 # both 4 and 5 positional arguments.



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] e8a2fd5 - An SBValue whose underlying ValueObject has no valid value, but does

2023-02-28 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-02-28T16:41:20-08:00
New Revision: e8a2fd5e7be23e4087e7ff58efa354dfae1a17c4

URL: 
https://github.com/llvm/llvm-project/commit/e8a2fd5e7be23e4087e7ff58efa354dfae1a17c4
DIFF: 
https://github.com/llvm/llvm-project/commit/e8a2fd5e7be23e4087e7ff58efa354dfae1a17c4.diff

LOG: An SBValue whose underlying ValueObject has no valid value, but does
hold an error should:

(a) return false for IsValid, since that's the current behavior and is
a convenient way to check "should I get the value for this".
(b) preserve the error when an SBValue is made from it, and print the
error in the ValueObjectPrinter.

Make that happen.

Differential Revision: https://reviews.llvm.org/D144664

Added: 


Modified: 
lldb/source/API/SBValue.cpp
lldb/source/Core/ValueObject.cpp
lldb/source/DataFormatters/ValueObjectPrinter.cpp

Removed: 




diff  --git a/lldb/source/API/SBValue.cpp b/lldb/source/API/SBValue.cpp
index f9e03172a4d0f..ecd16ccf83a8f 100644
--- a/lldb/source/API/SBValue.cpp
+++ b/lldb/source/API/SBValue.cpp
@@ -114,6 +114,10 @@ class ValueImpl {
 lldb::ValueObjectSP value_sp = m_valobj_sp;
 
 Target *target = value_sp->GetTargetSP().get();
+// If this ValueObject holds an error, then it is valuable for that.
+if (value_sp->GetError().Fail()) 
+  return value_sp;
+
 if (!target)
   return ValueObjectSP();
 
@@ -1047,7 +1051,12 @@ lldb::SBFrame SBValue::GetFrame() {
 }
 
 lldb::ValueObjectSP SBValue::GetSP(ValueLocker ) const {
-  if (!m_opaque_sp || !m_opaque_sp->IsValid()) {
+  // IsValid means that the SBValue has a value in it.  But that's not the
+  // only time that ValueObjects are useful.  We also want to return the value
+  // if there's an error state in it.
+  if (!m_opaque_sp || (!m_opaque_sp->IsValid() 
+  && (m_opaque_sp->GetRootSP() 
+  && !m_opaque_sp->GetRootSP()->GetError().Fail( {
 locker.GetError().SetErrorString("No value");
 return ValueObjectSP();
   }

diff  --git a/lldb/source/Core/ValueObject.cpp 
b/lldb/source/Core/ValueObject.cpp
index 38645b087435d..6e79a04d024e5 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -1173,6 +1173,15 @@ bool ValueObject::DumpPrintableRepresentation(
 Stream , ValueObjectRepresentationStyle val_obj_display,
 Format custom_format, PrintableRepresentationSpecialCases special,
 bool do_dump_error) {
+
+  // If the ValueObject has an error, we might end up dumping the type, which
+  // is useful, but if we don't even have a type, then don't examine the object
+  // further as that's not meaningful, only the error is.
+  if (m_error.Fail() && !GetCompilerType().IsValid()) {
+if (do_dump_error)
+  s.Printf("<%s>", m_error.AsCString());
+return false;
+  }
 
   Flags flags(GetTypeInfo());
 
@@ -1374,6 +1383,8 @@ bool ValueObject::DumpPrintableRepresentation(
 if (!str.empty())
   s << str;
 else {
+  // We checked for errors at the start, but do it again here in case
+  // realizing the value for dumping produced an error.
   if (m_error.Fail()) {
 if (do_dump_error)
   s.Printf("<%s>", m_error.AsCString());

diff  --git a/lldb/source/DataFormatters/ValueObjectPrinter.cpp 
b/lldb/source/DataFormatters/ValueObjectPrinter.cpp
index c4221a5ac7cc0..17e9877bd5242 100644
--- a/lldb/source/DataFormatters/ValueObjectPrinter.cpp
+++ b/lldb/source/DataFormatters/ValueObjectPrinter.cpp
@@ -71,6 +71,18 @@ void ValueObjectPrinter::Init(
 }
 
 bool ValueObjectPrinter::PrintValueObject() {
+  if (!m_orig_valobj)
+return false;
+
+  // If the incoming ValueObject is in an error state, the best we're going to 
+  // get out of it is its type.  But if we don't even have that, just print
+  // the error and exit early.
+  if (m_orig_valobj->GetError().Fail() 
+  && !m_orig_valobj->GetCompilerType().IsValid()) {
+m_stream->Printf("Error: '%s'", m_orig_valobj->GetError().AsCString());
+return true;
+  }
+   
   if (!GetMostSpecializedValue() || m_valobj == nullptr)
 return false;
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 4eb694e - Add SBCommandInterpreter::UserCommandExists parallel to CommandExists.

2023-02-28 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-02-28T15:58:14-08:00
New Revision: 4eb694e35dd514395819b375b31a80bd6d58378e

URL: 
https://github.com/llvm/llvm-project/commit/4eb694e35dd514395819b375b31a80bd6d58378e
DIFF: 
https://github.com/llvm/llvm-project/commit/4eb694e35dd514395819b375b31a80bd6d58378e.diff

LOG: Add SBCommandInterpreter::UserCommandExists parallel to CommandExists.

The latter only checks built-in commands.  I also added some docs to
make the distinction clear and a test.

Differential Revision: https://reviews.llvm.org/D144929

Added: 


Modified: 
lldb/include/lldb/API/SBCommandInterpreter.h
lldb/source/API/SBCommandInterpreter.cpp
lldb/test/API/commands/command/script/TestCommandScript.py

Removed: 




diff  --git a/lldb/include/lldb/API/SBCommandInterpreter.h 
b/lldb/include/lldb/API/SBCommandInterpreter.h
index 0830145bc2544..08ed989714d13 100644
--- a/lldb/include/lldb/API/SBCommandInterpreter.h
+++ b/lldb/include/lldb/API/SBCommandInterpreter.h
@@ -45,8 +45,34 @@ class SBCommandInterpreter {
 
   bool IsValid() const;
 
+  /// Return whether a built-in command with the passed in
+  /// name or command path exists.
+  ///
+  /// \param[in] cmd
+  ///   The command or command path to search for.
+  ///
+  /// \return
+  ///   \b true if the command exists, \b false otherwise.
   bool CommandExists(const char *cmd);
 
+  /// Return whether a user defined command with the passed in
+  /// name or command path exists.
+  ///
+  /// \param[in] cmd
+  ///   The command or command path to search for.
+  ///
+  /// \return
+  ///   \b true if the command exists, \b false otherwise.
+  bool UserCommandExists(const char *cmd);
+
+  /// Return whether the passed in name or command path
+  /// exists and is an alias to some other command.
+  ///
+  /// \param[in] cmd
+  ///   The command or command path to search for.
+  ///
+  /// \return
+  ///   \b true if the command exists, \b false otherwise.
   bool AliasExists(const char *cmd);
 
   lldb::SBBroadcaster GetBroadcaster();

diff  --git a/lldb/source/API/SBCommandInterpreter.cpp 
b/lldb/source/API/SBCommandInterpreter.cpp
index cd6ef3b23fd41..35c55283855df 100644
--- a/lldb/source/API/SBCommandInterpreter.cpp
+++ b/lldb/source/API/SBCommandInterpreter.cpp
@@ -118,6 +118,13 @@ bool SBCommandInterpreter::CommandExists(const char *cmd) {
   : false);
 }
 
+bool SBCommandInterpreter::UserCommandExists(const char *cmd) {
+  LLDB_INSTRUMENT_VA(this, cmd);
+
+  return (((cmd != nullptr) && IsValid()) ? 
m_opaque_ptr->UserCommandExists(cmd)
+  : false);
+}
+
 bool SBCommandInterpreter::AliasExists(const char *cmd) {
   LLDB_INSTRUMENT_VA(this, cmd);
 

diff  --git a/lldb/test/API/commands/command/script/TestCommandScript.py 
b/lldb/test/API/commands/command/script/TestCommandScript.py
index 7e8206ca96a48..b81acef261067 100644
--- a/lldb/test/API/commands/command/script/TestCommandScript.py
+++ b/lldb/test/API/commands/command/script/TestCommandScript.py
@@ -19,6 +19,11 @@ def test(self):
 def pycmd_tests(self):
 self.runCmd("command source py_import")
 
+# Test that we did indeed add these commands as user commands:
+interp = self.dbg.GetCommandInterpreter()
+self.expectTrue(interp.UserCommandExists("foobar"), "foobar exists")
+self.expectFalse(interp.CommandExists("foobar"), "It is not a 
builtin.")
+
 # Test a bunch of 
diff erent kinds of python callables with
 # both 4 and 5 positional arguments.
 self.expect("foobar", substrs=["All good"])



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 9093f3c - Report a useful error when someone passes an incorrect python class name.

2023-02-14 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-02-14T13:47:14-08:00
New Revision: 9093f3c39b8fa8ef836c627e1db329cd7349e9bb

URL: 
https://github.com/llvm/llvm-project/commit/9093f3c39b8fa8ef836c627e1db329cd7349e9bb
DIFF: 
https://github.com/llvm/llvm-project/commit/9093f3c39b8fa8ef836c627e1db329cd7349e9bb.diff

LOG: Report a useful error when someone passes an incorrect python class name.

Added: 


Modified: 
lldb/source/Commands/CommandObjectCommands.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/test/API/commands/command/script/TestCommandScript.py

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index f06dec8328c9d..254e226772dfa 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -1600,7 +1600,8 @@ class CommandObjectCommandsScriptAdd : public 
CommandObjectParsed,
   auto cmd_obj_sp = interpreter->CreateScriptCommandObject(
   m_options.m_class_name.c_str());
   if (!cmd_obj_sp) {
-result.AppendError("cannot create helper object");
+result.AppendErrorWithFormatv("cannot create helper object for: "
+  "'{0}'", m_options.m_class_name);
 return false;
   }
 

diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 3c0aa29071968..1a2307424750d 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -1949,8 +1949,11 @@ 
ScriptInterpreterPythonImpl::CreateScriptCommandObject(const char *class_name) {
   PythonObject ret_val = LLDBSwigPythonCreateCommandObject(
   class_name, m_dictionary_name.c_str(), debugger_sp);
 
-  return StructuredData::GenericSP(
-  new StructuredPythonObject(std::move(ret_val)));
+  if (ret_val.IsValid())
+return StructuredData::GenericSP(
+new StructuredPythonObject(std::move(ret_val)));
+  else
+return {};
 }
 
 bool ScriptInterpreterPythonImpl::GenerateTypeScriptFunction(

diff  --git a/lldb/test/API/commands/command/script/TestCommandScript.py 
b/lldb/test/API/commands/command/script/TestCommandScript.py
index 756cb4a3632f8..7e8206ca96a48 100644
--- a/lldb/test/API/commands/command/script/TestCommandScript.py
+++ b/lldb/test/API/commands/command/script/TestCommandScript.py
@@ -164,6 +164,10 @@ def cleanup():
 # This should not crash.
 self.runCmd('bug11569', check=False)
 
+# Make sure that a reference to a non-existent class raises an error:
+bad_class_name = "LLDBNoSuchModule.LLDBNoSuchClass"
+self.expect("command script add wont-work --class 
{0}".format(bad_class_name), error=True, substrs = [bad_class_name])
+
 def test_persistence(self):
 """
 Ensure that function arguments meaningfully persist (and do not crash!)



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] d980860 - Add usage info for backtick to the lldb tutorial.

2023-02-02 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-02-02T13:47:12-08:00
New Revision: d98086036a62e4e9c912c3b15bf16893d3df41da

URL: 
https://github.com/llvm/llvm-project/commit/d98086036a62e4e9c912c3b15bf16893d3df41da
DIFF: 
https://github.com/llvm/llvm-project/commit/d98086036a62e4e9c912c3b15bf16893d3df41da.diff

LOG: Add usage info for backtick to the lldb tutorial.

Added: 


Modified: 
lldb/docs/use/tutorial.rst

Removed: 




diff  --git a/lldb/docs/use/tutorial.rst b/lldb/docs/use/tutorial.rst
index d4da0bae5aaf0..9c807ce4bb55d 100644
--- a/lldb/docs/use/tutorial.rst
+++ b/lldb/docs/use/tutorial.rst
@@ -20,10 +20,23 @@ Unlike gdb's command set, which is rather free-form, we 
tried to make the lldb c
 The command line parsing is done before command execution, so it is uniform
 across all the commands. The command syntax for basic commands is very simple,
 arguments, options and option values are all white-space separated, and
-double-quotes are used to protect white-spaces in an argument. If you need to
-put a backslash or double-quote character in an argument you back-slash it in
-the argument. That makes the command syntax more regular, but it also means you
-may have to quote some arguments in lldb that you wouldn't in gdb.
+either single or double-quotes (in pairs) are used to protect white-spaces
+in an argument.  If you need to put a backslash or double-quote character in an
+argument you back-slash it in the argument. That makes the command syntax more
+regular, but it also means you may have to quote some arguments in lldb that
+you wouldn't in gdb.
+
+There is one other special quote character in lldb - the backtick.
+If you put backticks around an argument or option value, lldb will run the text
+of the value through the expression parser, and the result of the expression
+will be passed to the command.  So for instance, if "len" is a local
+int variable with the value 5, then the command:
+
+::
+
+   (lldb) memory read -c `len` 0x12345
+
+will receive the value 5 for the count option, rather than the string "len".
 
 
 Options can be placed anywhere on the command line, but if the arguments begin



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 4adabb8 - Fix typo: FineLineEntriesForFileIndex -> FindLineEntriesForFileIndex.

2023-02-01 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-02-01T16:41:17-08:00
New Revision: 4adabb8786b87e9f105e37d5606e1c0187abc647

URL: 
https://github.com/llvm/llvm-project/commit/4adabb8786b87e9f105e37d5606e1c0187abc647
DIFF: 
https://github.com/llvm/llvm-project/commit/4adabb8786b87e9f105e37d5606e1c0187abc647.diff

LOG: Fix typo: FineLineEntriesForFileIndex -> FindLineEntriesForFileIndex.

Added: 


Modified: 
lldb/include/lldb/Symbol/LineTable.h
lldb/source/Core/FileLineResolver.cpp
lldb/source/Symbol/LineTable.cpp

Removed: 




diff  --git a/lldb/include/lldb/Symbol/LineTable.h 
b/lldb/include/lldb/Symbol/LineTable.h
index 7fca44b5930b7..6d158ab518879 100644
--- a/lldb/include/lldb/Symbol/LineTable.h
+++ b/lldb/include/lldb/Symbol/LineTable.h
@@ -161,7 +161,7 @@ class LineTable {
   uint32_t start_idx, const std::vector _idx,
   const SourceLocationSpec _location_spec, LineEntry *line_entry_ptr);
 
-  size_t FineLineEntriesForFileIndex(uint32_t file_idx, bool append,
+  size_t FindLineEntriesForFileIndex(uint32_t file_idx, bool append,
  SymbolContextList _list);
 
   /// Get the line entry from the line table at index \a idx.

diff  --git a/lldb/source/Core/FileLineResolver.cpp 
b/lldb/source/Core/FileLineResolver.cpp
index 2cf7007165bc6..612614a41bb0e 100644
--- a/lldb/source/Core/FileLineResolver.cpp
+++ b/lldb/source/Core/FileLineResolver.cpp
@@ -48,7 +48,7 @@ FileLineResolver::SearchCallback(SearchFilter , 
SymbolContext ,
   // Match all lines in a file...
   const bool append = true;
   while (file_idx != UINT32_MAX) {
-line_table->FineLineEntriesForFileIndex(file_idx, append,
+line_table->FindLineEntriesForFileIndex(file_idx, append,
 m_sc_list);
 // Get the next file index in case we have multiple file entries
 // for the same file

diff  --git a/lldb/source/Symbol/LineTable.cpp 
b/lldb/source/Symbol/LineTable.cpp
index cd8d520ada781..59b5d6125e04e 100644
--- a/lldb/source/Symbol/LineTable.cpp
+++ b/lldb/source/Symbol/LineTable.cpp
@@ -325,7 +325,7 @@ uint32_t LineTable::FindLineEntryIndexByFileIndex(
   start_idx, file_idx, src_location_spec, line_entry_ptr, 
file_idx_matcher);
 }
 
-size_t LineTable::FineLineEntriesForFileIndex(uint32_t file_idx, bool append,
+size_t LineTable::FindLineEntriesForFileIndex(uint32_t file_idx, bool append,
   SymbolContextList _list) {
 
   if (!append)



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] e12a950 - Remove the LINK_COMPONENTS entry from lldb-instr CMakery

2023-01-20 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-01-20T15:41:59-08:00
New Revision: e12a950d90f88aeddaa97d6e7c8fd0bfedc42f73

URL: 
https://github.com/llvm/llvm-project/commit/e12a950d90f88aeddaa97d6e7c8fd0bfedc42f73
DIFF: 
https://github.com/llvm/llvm-project/commit/e12a950d90f88aeddaa97d6e7c8fd0bfedc42f73.diff

LOG: Remove the LINK_COMPONENTS entry from lldb-instr CMakery

The presence of this entry causes the Xcode generator to produce
two references to libLLVMSupport.a, one at the end of the list, and
that causes the build to fail with a link error.  The first version
was pulled in when processing the CLANG_LIBS entries in the
lldb/tools/lldb-instr/CMakeLists.txt.

I looked around and the only places where we use LINK_COMPONENTS and
CLANG_LIBS together are various lldb subdirectories that produce .a
files but don't actually link anything.

Anyway, this line doesn't seem to be needed for either the regular
Ninja or the Xcode generator, and removing it makes the xcode build
work again.

Differential Revision: https://reviews.llvm.org/D142241

Added: 


Modified: 
lldb/tools/lldb-instr/CMakeLists.txt

Removed: 




diff  --git a/lldb/tools/lldb-instr/CMakeLists.txt 
b/lldb/tools/lldb-instr/CMakeLists.txt
index 8da453b2894fd..a1bbd7e2b7c93 100644
--- a/lldb/tools/lldb-instr/CMakeLists.txt
+++ b/lldb/tools/lldb-instr/CMakeLists.txt
@@ -11,6 +11,4 @@ add_lldb_tool(lldb-instr
 clangSerialization
 clangTooling
 
-  LINK_COMPONENTS
-Support
   )



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 887240f - Remove the undocumented `help` subcommand.

2023-01-19 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2023-01-19T12:03:06-08:00
New Revision: 887240faf769395511d1568b4e50aafc6fe3b696

URL: 
https://github.com/llvm/llvm-project/commit/887240faf769395511d1568b4e50aafc6fe3b696
DIFF: 
https://github.com/llvm/llvm-project/commit/887240faf769395511d1568b4e50aafc6fe3b696.diff

LOG: Remove the undocumented `help` subcommand.

This is processed by hand in CommandObjectMultiword, and is undiscoverable,
it doesn't work in all cases.  Because it is a bare word, it can't really be
extended w/o introducing the possibility of collisions as well.  If we did
want to do something like this we should add a --help flag to CommandObject.  
That
way the feature would be consistent and documented.

Differential Revision: https://reviews.llvm.org/D142067

Added: 


Modified: 
lldb/source/Commands/CommandObjectMultiword.cpp
lldb/test/API/functionalities/multiword-commands/TestMultiWordCommands.py

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectMultiword.cpp 
b/lldb/source/Commands/CommandObjectMultiword.cpp
index 6bcf0dea03868..bae2717ffe68e 100644
--- a/lldb/source/Commands/CommandObjectMultiword.cpp
+++ b/lldb/source/Commands/CommandObjectMultiword.cpp
@@ -174,11 +174,6 @@ bool CommandObjectMultiword::Execute(const char 
*args_string,
 return result.Succeeded();
   }
 
-  if (sub_command.equals_insensitive("help")) {
-this->CommandObject::GenerateHelpText(result);
-return result.Succeeded();
-  }
-
   if (m_subcommand_dict.empty()) {
 result.AppendErrorWithFormat("'%s' does not have any subcommands.\n",
  GetCommandName().str().c_str());

diff  --git 
a/lldb/test/API/functionalities/multiword-commands/TestMultiWordCommands.py 
b/lldb/test/API/functionalities/multiword-commands/TestMultiWordCommands.py
index e8b14d1629e1b..70a8b44b8d13f 100644
--- a/lldb/test/API/functionalities/multiword-commands/TestMultiWordCommands.py
+++ b/lldb/test/API/functionalities/multiword-commands/TestMultiWordCommands.py
@@ -19,13 +19,3 @@ def test_ambiguous_subcommand(self):
 @no_debug_info_test
 def test_empty_subcommand(self):
 self.expect("platform \"\"", error=True, substrs=["Need to specify a 
non-empty subcommand."])
-
-@no_debug_info_test
-def test_help(self):
-#  help brings up help.
-self.expect("platform help",
-substrs=["Commands to manage and create platforms.",
- "Syntax: platform [",
- "The following subcommands are supported:",
- "connect",
- "Select the current platform"])



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 3b7ac5b - Fix GetAddressOf for children of pointer ValueObjectConstResult* variables.

2022-12-09 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-12-09T11:16:10-08:00
New Revision: 3b7ac5b295df7381cee277342085f52fe468e633

URL: 
https://github.com/llvm/llvm-project/commit/3b7ac5b295df7381cee277342085f52fe468e633
DIFF: 
https://github.com/llvm/llvm-project/commit/3b7ac5b295df7381cee277342085f52fe468e633.diff

LOG: Fix GetAddressOf for children of pointer ValueObjectConstResult* variables.

The original code always set the m_live_address of children of the ValueObjects 
that
use ValueObjectConstResultImpl backends to the parent m_live_address + 
child_byte_offset.
That is correct for structure types, but wrong for pointer types, since 
m_live_address
for a pointer type is the address of the storage for the pointer, not of the 
pointee.

Also added a test which was failing before this patch.

Added: 
lldb/test/API/lang/c/parray_vrs_char_array/Makefile
lldb/test/API/lang/c/parray_vrs_char_array/TestParrayVrsCharArrayChild.py
lldb/test/API/lang/c/parray_vrs_char_array/main.c

Modified: 
lldb/source/Core/ValueObjectConstResultImpl.cpp

Removed: 




diff  --git a/lldb/source/Core/ValueObjectConstResultImpl.cpp 
b/lldb/source/Core/ValueObjectConstResultImpl.cpp
index fee1da138bbc6..e2db3ace19247 100644
--- a/lldb/source/Core/ValueObjectConstResultImpl.cpp
+++ b/lldb/source/Core/ValueObjectConstResultImpl.cpp
@@ -89,13 +89,20 @@ ValueObject *ValueObjectConstResultImpl::CreateChildAtIndex(
 if (!child_name_str.empty())
   child_name.SetCString(child_name_str.c_str());
 
+lldb::addr_t child_live_addr = LLDB_INVALID_ADDRESS;
+// Transfer the live address (with offset) to the child.  But if
+// the parent is a pointer, the live address is where that pointer
+// value lives in memory, so the children live addresses aren't
+// offsets from that value, they are just other load addresses that
+// are recorded in the Value of the child ValueObjects.
+if (m_live_address != LLDB_INVALID_ADDRESS) {
+  if (!compiler_type.IsPointerType())
+child_live_addr = m_live_address + child_byte_offset;
+}
 valobj = new ValueObjectConstResultChild(
 *m_impl_backend, child_compiler_type, child_name, child_byte_size,
 child_byte_offset, child_bitfield_bit_size, child_bitfield_bit_offset,
-child_is_base_class, child_is_deref_of_parent,
-m_live_address == LLDB_INVALID_ADDRESS
-? m_live_address
-: m_live_address + child_byte_offset,
+child_is_base_class, child_is_deref_of_parent, child_live_addr,
 language_flags);
   }
 

diff  --git a/lldb/test/API/lang/c/parray_vrs_char_array/Makefile 
b/lldb/test/API/lang/c/parray_vrs_char_array/Makefile
new file mode 100644
index 0..695335e068c0c
--- /dev/null
+++ b/lldb/test/API/lang/c/parray_vrs_char_array/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c
+CFLAGS_EXTRAS := -std=c99
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/lang/c/parray_vrs_char_array/TestParrayVrsCharArrayChild.py 
b/lldb/test/API/lang/c/parray_vrs_char_array/TestParrayVrsCharArrayChild.py
new file mode 100644
index 0..f1795516c74e1
--- /dev/null
+++ b/lldb/test/API/lang/c/parray_vrs_char_array/TestParrayVrsCharArrayChild.py
@@ -0,0 +1,37 @@
+"""
+Test that parray of a struct with an embedded char array works.
+This was failing because the "live address" of the child elements
+was calculated incorrectly - as a offset from the pointer live 
+address.  It only happened for char[] children because they used
+GetAddressOf which relies on the live address.
+"""
+
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+class TestParrayVrsCharArrayChild(TestBase):
+
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_parray_struct_with_char_array_child(self):
+"""This is the basic test for does parray get the char values right."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.do_array_test()
+
+def do_array_test(self):
+(target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+   "Set a breakpoint here", 
self.main_source_file)
+
+frame = thread.GetFrameAtIndex(0)
+ 
+self.expect("expr -Z 3 -- struct_ptr",
+substrs = ['before = 112, var = "abcd", after = 221',
+   'before = 313, var = "efgh", after = 414',
+   'before = 515, var = "ijkl", after = 616'])
+
+

diff  --git a/lldb/test/API/lang/c/parray_vrs_char_array/main.c 
b/lldb/test/API/lang/c/parray_vrs_char_array/main.c
new file mode 100644
index 0..0571a6bc5f66d
--- /dev/null
+++ b/lldb/test/API/lang/c/parray_vrs_char_array/main.c
@@ -0,0 +1,15 @@
+struct MyStruct {
+  int before;
+  char var[5];
+  int after;
+};
+
+int
+main()
+{
+  struct MyStruct struct_arr[3] = 

[Lldb-commits] [lldb] 9c5877f - Switch the "command script add" interactive input to use the new command form.

2022-12-09 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-12-09T10:58:15-08:00
New Revision: 9c5877f33d9f7fd317c07920fd24a041ad69077a

URL: 
https://github.com/llvm/llvm-project/commit/9c5877f33d9f7fd317c07920fd24a041ad69077a
DIFF: 
https://github.com/llvm/llvm-project/commit/9c5877f33d9f7fd317c07920fd24a041ad69077a.diff

LOG: Switch the "command script add" interactive input to use the new command 
form.

We're suggesting people use the form of the command that takes an exe_ctx - it
is both more convenient and more correct - since you should not be using
GetSelected{Target, Process, etc.} in commands.

Added: 
lldb/test/Shell/Commands/command-script-add.test

Modified: 
lldb/source/Commands/CommandObjectCommands.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index 9bf07f3eba780..422291f1cd5a5 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -201,7 +201,7 @@ class CommandObjectCommandsSource : public 
CommandObjectParsed {
 static const char *g_python_command_instructions =
 "Enter your Python command(s). Type 'DONE' to end.\n"
 "You must define a Python function with this signature:\n"
-"def my_command_impl(debugger, args, result, internal_dict):\n";
+"def my_command_impl(debugger, args, exe_ctx, result, internal_dict):\n";
 
 class CommandObjectCommandsAlias : public CommandObjectRaw {
 protected:

diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 810c77925f5b7..117a057d8d7c5 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -1369,7 +1369,7 @@ bool 
ScriptInterpreterPythonImpl::GenerateScriptAliasFunction(
   std::string auto_generated_function_name(GenerateUniqueName(
   "lldb_autogen_python_cmd_alias_func", num_created_functions));
 
-  sstr.Printf("def %s (debugger, args, result, internal_dict):",
+  sstr.Printf("def %s (debugger, args, exe_ctx, result, internal_dict):",
   auto_generated_function_name.c_str());
 
   if (!GenerateFunction(sstr.GetData(), user_input).Success())

diff  --git a/lldb/test/Shell/Commands/command-script-add.test 
b/lldb/test/Shell/Commands/command-script-add.test
new file mode 100644
index 0..5ffada069a610
--- /dev/null
+++ b/lldb/test/Shell/Commands/command-script-add.test
@@ -0,0 +1,9 @@
+# Test that command script add with no arguments prompts for
+# and generates the modern (exe_ctx) version of the command.
+
+# RUN: %lldb < %s | FileCheck %s
+command script add doit
+print(exe_ctx.target)
+DONE
+doit
+# CHECK: No value



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 0ec24e1 - Only use major version in the clang resource directory for standalone builds.

2022-11-16 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-11-16T16:00:26-08:00
New Revision: 0ec24e1f956616c54f38e104b482dec9309a93fa

URL: 
https://github.com/llvm/llvm-project/commit/0ec24e1f956616c54f38e104b482dec9309a93fa
DIFF: 
https://github.com/llvm/llvm-project/commit/0ec24e1f956616c54f38e104b482dec9309a93fa.diff

LOG: Only use major version in the clang resource directory for standalone 
builds.

Commit e1b88c8a09be changed the name of the clang resource directory so that
it was "lib/clang/" but missed the place in the LLDB standalone
build where we search for the resource directory.  That was still looking for
...  The standalone lldb bot has been failing since this
commit.

Added: 


Modified: 
lldb/cmake/modules/LLDBConfig.cmake

Removed: 




diff  --git a/lldb/cmake/modules/LLDBConfig.cmake 
b/lldb/cmake/modules/LLDBConfig.cmake
index 2dd14d05a92aa..1079e4b2def17 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -271,7 +271,7 @@ endif()
 # directory that LLDB is using for its embedded Clang instance needs to point
 # to the resource directory of the used Clang installation.
 if (NOT TARGET clang-resource-headers)
-  set(LLDB_CLANG_RESOURCE_DIR_NAME 
"${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}")
+  set(LLDB_CLANG_RESOURCE_DIR_NAME "${LLVM_VERSION_MAJOR}")
   # Iterate over the possible places where the external resource directory
   # could be and pick the first that exists.
   foreach(CANDIDATE "${Clang_DIR}/../.." "${LLVM_DIR}" "${LLVM_LIBRARY_DIRS}"



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 353f265 - Apparently I moved the wrong one to "2", then Jason moved the right

2022-11-10 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-11-10T15:23:51-08:00
New Revision: 353f265283e9ab209b544ab6818f3bd6ca071873

URL: 
https://github.com/llvm/llvm-project/commit/353f265283e9ab209b544ab6818f3bd6ca071873
DIFF: 
https://github.com/llvm/llvm-project/commit/353f265283e9ab209b544ab6818f3bd6ca071873.diff

LOG: Apparently I moved the wrong one to "2", then Jason moved the right
one, so this commit moves the wrong one back to no-"2"...

Added: 
lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py

Modified: 


Removed: 
lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py



diff  --git a/lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py 
b/lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py
similarity index 100%
rename from lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py
rename to lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] d518ed4 - Handle aliasing a non-top-level command.

2022-11-09 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-11-09T10:11:16-08:00
New Revision: d518ed42ae85786c371fd4578f72ab7eb286cb30

URL: 
https://github.com/llvm/llvm-project/commit/d518ed42ae85786c371fd4578f72ab7eb286cb30
DIFF: 
https://github.com/llvm/llvm-project/commit/d518ed42ae85786c371fd4578f72ab7eb286cb30.diff

LOG: Handle aliasing a non-top-level command.

This didn't work previously because we had to check whether the incoming
command was an alias command, but if it wasn't we still used the result
of that lookup - which was by the command's node name.  That fails for
non-top-level commands.  In this case, the resolution is pretty simple since
we already have the node's CommandObject, so all we needed to do was turn
it into a shared pointer, for which I added enable_shared_from_this to the
CommandObject.

Differential Revision: https://reviews.llvm.org/D137662

Added: 


Modified: 
lldb/include/lldb/Interpreter/CommandObject.h
lldb/source/Commands/CommandObjectCommands.cpp
lldb/test/API/commands/command/container/TestContainerCommands.py

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/CommandObject.h 
b/lldb/include/lldb/Interpreter/CommandObject.h
index ad5884e207a17..fc058eb50a5e5 100644
--- a/lldb/include/lldb/Interpreter/CommandObject.h
+++ b/lldb/include/lldb/Interpreter/CommandObject.h
@@ -10,6 +10,7 @@
 #define LLDB_INTERPRETER_COMMANDOBJECT_H
 
 #include 
+#include 
 #include 
 #include 
 
@@ -64,7 +65,7 @@ size_t FindLongestCommandWord(std::map ) {
   return max_len;
 }
 
-class CommandObject {
+class CommandObject : public std::enable_shared_from_this {
 public:
   typedef llvm::StringRef(ArgumentHelpCallbackFunction)();
 

diff  --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index 3d4893de29f69..9bf07f3eba780 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -485,29 +485,31 @@ rather than using a positional placeholder:"
 OptionArgVectorSP(new OptionArgVector);
 
 const bool include_aliases = true;
-if (CommandObjectSP cmd_obj_sp = m_interpreter.GetCommandSPExact(
-cmd_obj.GetCommandName(), include_aliases)) {
-  if (m_interpreter.AliasExists(alias_command) ||
-  m_interpreter.UserCommandExists(alias_command)) {
-result.AppendWarningWithFormat(
-"Overwriting existing definition for '%s'.\n",
-alias_command.str().c_str());
-  }
-  if (CommandAlias *alias = m_interpreter.AddAlias(
-  alias_command, cmd_obj_sp, raw_command_string)) {
-if (m_command_options.m_help.OptionWasSet())
-  alias->SetHelp(m_command_options.m_help.GetCurrentValue());
-if (m_command_options.m_long_help.OptionWasSet())
-  alias->SetHelpLong(m_command_options.m_long_help.GetCurrentValue());
-result.SetStatus(eReturnStatusSuccessFinishNoResult);
-  } else {
-result.AppendError("Unable to create requested alias.\n");
-  }
+// Look up the command using command's name first.  This is to resolve
+// aliases when you are making nested aliases.  But if you don't find
+// it that way, then it wasn't an alias and we can just use the object
+// we were passed in.
+CommandObjectSP cmd_obj_sp = m_interpreter.GetCommandSPExact(
+cmd_obj.GetCommandName(), include_aliases);
+if (!cmd_obj_sp)
+  cmd_obj_sp = cmd_obj.shared_from_this();
 
+if (m_interpreter.AliasExists(alias_command) ||
+m_interpreter.UserCommandExists(alias_command)) {
+  result.AppendWarningWithFormat(
+  "Overwriting existing definition for '%s'.\n",
+  alias_command.str().c_str());
+}
+if (CommandAlias *alias = m_interpreter.AddAlias(
+alias_command, cmd_obj_sp, raw_command_string)) {
+  if (m_command_options.m_help.OptionWasSet())
+alias->SetHelp(m_command_options.m_help.GetCurrentValue());
+  if (m_command_options.m_long_help.OptionWasSet())
+alias->SetHelpLong(m_command_options.m_long_help.GetCurrentValue());
+  result.SetStatus(eReturnStatusSuccessFinishNoResult);
 } else {
   result.AppendError("Unable to create requested alias.\n");
 }
-
 return result.Succeeded();
   }
 

diff  --git a/lldb/test/API/commands/command/container/TestContainerCommands.py 
b/lldb/test/API/commands/command/container/TestContainerCommands.py
index 2267b3528a558..76f981c7dd2af 100644
--- a/lldb/test/API/commands/command/container/TestContainerCommands.py
+++ b/lldb/test/API/commands/command/container/TestContainerCommands.py
@@ -55,6 +55,12 @@ def container_add(self):
 self.expect("test-multi test-multi-sub welcome friend", "Test command 
works",
 substrs=["Hello friend, welcome to LLDB"])
 
+# Make sure we can make an alias to this:
+

[Lldb-commits] [lldb] b565e7f - Don't try to create Expressions when the process is running.

2022-11-09 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-11-09T10:07:09-08:00
New Revision: b565e7f0c4cb1768f6c43499aed95adb8cc4f04a

URL: 
https://github.com/llvm/llvm-project/commit/b565e7f0c4cb1768f6c43499aed95adb8cc4f04a
DIFF: 
https://github.com/llvm/llvm-project/commit/b565e7f0c4cb1768f6c43499aed95adb8cc4f04a.diff

LOG: Don't try to create Expressions when the process is running.

We generally prohibit this at a higher level - for instance requiring
the process to be stopped for "expr".  But when we trigger an expression
for internal purposes (e.g. to fetch types from the ObjC runtime) we weren't
checking the process state.  Now we explicitly check this at the very start
of the job so we don't get into bad states.

Differential Revision: https://reviews.llvm.org/D137684

Added: 


Modified: 
lldb/source/Expression/FunctionCaller.cpp
lldb/source/Expression/UserExpression.cpp
lldb/source/Expression/UtilityFunction.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
lldb/source/Target/Process.cpp

Removed: 




diff  --git a/lldb/source/Expression/FunctionCaller.cpp 
b/lldb/source/Expression/FunctionCaller.cpp
index 58c9d56b089c0..ffadbf9b32ec5 100644
--- a/lldb/source/Expression/FunctionCaller.cpp
+++ b/lldb/source/Expression/FunctionCaller.cpp
@@ -66,17 +66,31 @@ bool FunctionCaller::WriteFunctionWrapper(
 ExecutionContext _ctx, DiagnosticManager _manager) {
   Process *process = exe_ctx.GetProcessPtr();
 
-  if (!process)
+  if (!process) {
+diagnostic_manager.Printf(eDiagnosticSeverityError, "no process.");
 return false;
-
+  }
+  
   lldb::ProcessSP jit_process_sp(m_jit_process_wp.lock());
 
-  if (process != jit_process_sp.get())
+  if (process != jit_process_sp.get()) {
+diagnostic_manager.Printf(eDiagnosticSeverityError,
+ "process does not match the stored process.");
 return false;
-
-  if (!m_compiled)
+  }
+
+  if (process->GetState() != lldb::eStateStopped) {
+diagnostic_manager.Printf(eDiagnosticSeverityError, 
+  "process is not stopped");
 return false;
+  }
 
+  if (!m_compiled) {
+diagnostic_manager.Printf(eDiagnosticSeverityError, 
+  "function not compiled");
+return false;
+  }
+  
   if (m_JITted)
 return true;
 
@@ -213,6 +227,17 @@ bool FunctionCaller::WriteFunctionArguments(
 bool FunctionCaller::InsertFunction(ExecutionContext _ctx,
 lldb::addr_t _addr_ref,
 DiagnosticManager _manager) {
+  // Since we might need to call allocate memory and maybe call code to make
+  // the caller, we need to be stopped.
+  Process *process = exe_ctx.GetProcessPtr();
+  if (!process) {
+diagnostic_manager.PutString(eDiagnosticSeverityError, "no process");
+return false;
+  }
+  if (process->GetState() != lldb::eStateStopped) {
+diagnostic_manager.PutString(eDiagnosticSeverityError, "process running");
+return false;
+  }
   if (CompileFunction(exe_ctx.GetThreadSP(), diagnostic_manager) != 0)
 return false;
   if (!WriteFunctionWrapper(exe_ctx, diagnostic_manager))

diff  --git a/lldb/source/Expression/UserExpression.cpp 
b/lldb/source/Expression/UserExpression.cpp
index 186e414e68793..c1515b0ace817 100644
--- a/lldb/source/Expression/UserExpression.cpp
+++ b/lldb/source/Expression/UserExpression.cpp
@@ -194,16 +194,22 @@ UserExpression::Evaluate(ExecutionContext _ctx,
 
   Process *process = exe_ctx.GetProcessPtr();
 
-  if (process == nullptr || process->GetState() != lldb::eStateStopped) {
-if (execution_policy == eExecutionPolicyAlways) {
-  LLDB_LOG(log, "== [UserExpression::Evaluate] Expression may not run, but 
"
-"is not constant ==");
+  if (process == nullptr && execution_policy == eExecutionPolicyAlways) {
+LLDB_LOG(log, "== [UserExpression::Evaluate] No process, but the policy is 
"
+  "eExecutionPolicyAlways");
 
-  error.SetErrorString("expression needed to run but couldn't");
+error.SetErrorString("expression needed to run but couldn't: no process");
 
-  return execution_results;
-}
+return execution_results;
   }
+  // Since we might need to call allocate memory and maybe call code to make
+  // the caller, we need to be stopped.
+  if (process != nullptr && process->GetState() != lldb::eStateStopped) {
+error.SetErrorString("Can't make a function caller while the process is " 
+  "running");
+return execution_results;
+  }
+
 
   // Explicitly force the IR interpreter to evaluate the expression when the
   // there is no process that supports running the expression for us. Don't

diff  --git a/lldb/source/Expression/UtilityFunction.cpp 
b/lldb/source/Expression/UtilityFunction.cpp
index 1a4df97227065..5d55d9a5c2c1d 100644
--- 

[Lldb-commits] [lldb] 3b70e8b - Move the second instance of TestUniqueTypes.py to a unique file

2022-11-08 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-11-08T16:59:02-08:00
New Revision: 3b70e8b012f0f51eb0e2abeb38ee6c8914b90f9c

URL: 
https://github.com/llvm/llvm-project/commit/3b70e8b012f0f51eb0e2abeb38ee6c8914b90f9c
DIFF: 
https://github.com/llvm/llvm-project/commit/3b70e8b012f0f51eb0e2abeb38ee6c8914b90f9c.diff

LOG: Move the second instance of TestUniqueTypes.py to a unique file
name.  lldb-dotest.py errors out if two tests have the same filename.

Added: 
lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py

Modified: 


Removed: 
lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py



diff  --git a/lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py 
b/lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py
similarity index 100%
rename from lldb/test/API/lang/cpp/unique-types/TestUniqueTypes.py
rename to lldb/test/API/lang/cpp/unique-types/TestUniqueTypes2.py



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [lldb] d765664 - [lldb] Add matching based on Python callbacks for data formatters.

2022-10-19 Thread Jim Ingham via lldb-commits
Jorge,

It's great to see you worked your way through this change!

Something in our mail pipeline is dropping all my lldb-commits and review 
comment notifications.  Still haven't figured out who is doing that, so I 
didn't get a chance to look over the final version.

The code looks fine, but nobody will know how to use this if they don't read 
lldb source code fairly carefully, or browse our tests.

To finish off the feature, there should be an example to put in the examples 
directory, and there should be a paragraph showing how to use it in 
lldb/doc/use/formatting.rst.

It would also be good to add something an option to "type summary add" and 
"type synthetic add" to indicate that the name passed is neither a type name 
nor a regex but a recognizer function instead.  Maybe -R/--recognizer-function?

Is it too horrible of me to ask you to do these as a follow-up?  Otherwise I 
fear you will be the only one to use this feature...

Jim


> On Oct 19, 2022, at 12:54 PM, Jorge Gorbe Moya via lldb-commits 
>  wrote:
> 
> 
> Author: Jorge Gorbe Moya
> Date: 2022-10-19T12:53:38-07:00
> New Revision: d76566417e592cfac9c710f82575473b1b4a9285
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/d76566417e592cfac9c710f82575473b1b4a9285
> DIFF: 
> https://github.com/llvm/llvm-project/commit/d76566417e592cfac9c710f82575473b1b4a9285.diff
> 
> LOG: [lldb] Add matching based on Python callbacks for data formatters.
> 
> This patch adds a new matching method for data formatters, in addition
> to the existing exact typename and regex-based matching. The new method
> allows users to specify the name of a Python callback function that
> takes a `SBType` object and decides whether the type is a match or not.
> 
> Here is an overview of the changes performed:
> 
> - Add a new `eFormatterMatchCallback` matching type, and logic to handle
>  it in `TypeMatcher` and `SBTypeNameSpecifier`.
> 
> - Extend `FormattersMatchCandidate` instances with a pointer to the
>  current `ScriptInterpreter` and the `TypeImpl` corresponding to the
>  candidate type, so we can run registered callbacks and pass the type
>  to them. All matcher search functions now receive a
>  `FormattersMatchCandidate` instead of a type name.
> 
> - Add some glue code to ScriptInterpreterPython and the SWIG bindings to
>  allow calling a formatter matching callback. Most of this code is
>  modeled after the equivalent code for watchpoint callback functions.
> 
> - Add an API test for the new callback-based matching feature.
> 
> For more context, please check the RFC thread where this feature was
> originally discussed:
> https://discourse.llvm.org/t/rfc-python-callback-for-data-formatters-type-matching/64204/11
> 
> Differential Revision: https://reviews.llvm.org/D135648
> 
> Added: 
>lldb/test/API/functionalities/data-formatter/callback-matching/Makefile
>
> lldb/test/API/functionalities/data-formatter/callback-matching/TestDataFormatterCallbackMatching.py
>
> lldb/test/API/functionalities/data-formatter/callback-matching/formatters_with_callback.py
>lldb/test/API/functionalities/data-formatter/callback-matching/main.cpp
> 
> Modified: 
>lldb/bindings/python/python-swigsafecast.swig
>lldb/bindings/python/python-wrapper.swig
>lldb/include/lldb/API/SBType.h
>lldb/include/lldb/DataFormatters/DataVisualization.h
>lldb/include/lldb/DataFormatters/FormatClasses.h
>lldb/include/lldb/DataFormatters/FormatManager.h
>lldb/include/lldb/DataFormatters/FormattersContainer.h
>lldb/include/lldb/DataFormatters/TypeCategory.h
>lldb/include/lldb/DataFormatters/TypeCategoryMap.h
>lldb/include/lldb/Interpreter/ScriptInterpreter.h
>lldb/include/lldb/Target/Language.h
>lldb/include/lldb/lldb-enumerations.h
>lldb/source/API/SBTypeNameSpecifier.cpp
>lldb/source/Commands/CommandObjectType.cpp
>lldb/source/DataFormatters/DataVisualization.cpp
>lldb/source/DataFormatters/FormatManager.cpp
>lldb/source/DataFormatters/TypeCategory.cpp
>lldb/source/DataFormatters/TypeCategoryMap.cpp
>lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
>lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
>lldb/source/Plugins/ScriptInterpreter/Python/SWIGPythonBridge.h
>lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
>lldb/source/Target/Language.cpp
>lldb/unittests/DataFormatter/FormattersContainerTest.cpp
>lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/bindings/python/python-swigsafecast.swig 
> b/lldb/bindings/python/python-swigsafecast.swig
> index eb684133abef..aa5e8e50a2d9 100644
> --- a/lldb/bindings/python/python-swigsafecast.swig
> +++ b/lldb/bindings/python/python-swigsafecast.swig
> @@ -97,6 +97,10 @@ PythonObject 

[Lldb-commits] [lldb] 2c43cd8 - Turn off the warning that the undefined behavior I am using in

2022-10-04 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-10-04T11:38:32-07:00
New Revision: 2c43cd883c20b603bc7d9461bfa2591e80a36a3b

URL: 
https://github.com/llvm/llvm-project/commit/2c43cd883c20b603bc7d9461bfa2591e80a36a3b
DIFF: 
https://github.com/llvm/llvm-project/commit/2c43cd883c20b603bc7d9461bfa2591e80a36a3b.diff

LOG: Turn off the warning that the undefined behavior I am using in
a test generates.  The green dragon bot compiler is treating this
warning as an error for some reason, hopefully this will calm its
worries.

Added: 


Modified: 
lldb/test/API/functionalities/ubsan/basic/Makefile

Removed: 




diff  --git a/lldb/test/API/functionalities/ubsan/basic/Makefile 
b/lldb/test/API/functionalities/ubsan/basic/Makefile
index b27db90a40de2..caa15bff7b816 100644
--- a/lldb/test/API/functionalities/ubsan/basic/Makefile
+++ b/lldb/test/API/functionalities/ubsan/basic/Makefile
@@ -1,4 +1,4 @@
 C_SOURCES := main.c
-CFLAGS_EXTRAS := -fsanitize=undefined -g
+CFLAGS_EXTRAS := -fsanitize=undefined -g -Wno-int-conversion
 
 include Makefile.rules



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 852a4bd - Change the Sanitizer report breakpoint callbacks to asynchronous.

2022-10-03 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-10-03T18:10:28-07:00
New Revision: 852a4bdb25d145884f61cd812e66611e65fd2dd9

URL: 
https://github.com/llvm/llvm-project/commit/852a4bdb25d145884f61cd812e66611e65fd2dd9
DIFF: 
https://github.com/llvm/llvm-project/commit/852a4bdb25d145884f61cd812e66611e65fd2dd9.diff

LOG: Change the Sanitizer report breakpoint callbacks to asynchronous.

The synchronous callbacks are not intended to start the target running
during the callback, and doing so is flakey.  This patch converts them
to being regular async callbacks, and adds some testing for sequential
reports that have caused problems in the field.

Differential Revision: https://reviews.llvm.org/D134927

Added: 


Modified: 
lldb/include/lldb/Breakpoint/Breakpoint.h

lldb/source/Plugins/InstrumentationRuntime/ASan/InstrumentationRuntimeASan.cpp

lldb/source/Plugins/InstrumentationRuntime/MainThreadChecker/InstrumentationRuntimeMainThreadChecker.cpp

lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp

lldb/source/Plugins/InstrumentationRuntime/UBSan/InstrumentationRuntimeUBSan.cpp
lldb/source/Target/StopInfo.cpp
lldb/test/API/functionalities/ubsan/basic/TestUbsanBasic.py
lldb/test/API/functionalities/ubsan/basic/main.c

Removed: 




diff  --git a/lldb/include/lldb/Breakpoint/Breakpoint.h 
b/lldb/include/lldb/Breakpoint/Breakpoint.h
index 701d0823bd282..7490982cb05ba 100644
--- a/lldb/include/lldb/Breakpoint/Breakpoint.h
+++ b/lldb/include/lldb/Breakpoint/Breakpoint.h
@@ -382,7 +382,10 @@ class Breakpoint : public 
std::enable_shared_from_this,
   /// \param[in] is_synchronous
   ///If \b true the callback will be run on the private event thread
   ///before the stop event gets reported.  If false, the callback will get
-  ///handled on the public event thread after the stop has been posted.
+  ///handled on the public event thread while the stop event is being
+  ///pulled off the event queue.
+  ///Note: synchronous callbacks cannot cause the target to run, in
+  ///particular, they should not try to run the expression evaluator.
   void SetCallback(BreakpointHitCallback callback, void *baton,
bool is_synchronous = false);
 

diff  --git 
a/lldb/source/Plugins/InstrumentationRuntime/ASan/InstrumentationRuntimeASan.cpp
 
b/lldb/source/Plugins/InstrumentationRuntime/ASan/InstrumentationRuntimeASan.cpp
index 4746112873112..72dfbd5866224 100644
--- 
a/lldb/source/Plugins/InstrumentationRuntime/ASan/InstrumentationRuntimeASan.cpp
+++ 
b/lldb/source/Plugins/InstrumentationRuntime/ASan/InstrumentationRuntimeASan.cpp
@@ -299,14 +299,15 @@ void InstrumentationRuntimeASan::Activate() {
   if (symbol_address == LLDB_INVALID_ADDRESS)
 return;
 
-  bool internal = true;
-  bool hardware = false;
+  const bool internal = true;
+  const bool hardware = false;
+  const bool sync = false;
   Breakpoint *breakpoint =
   process_sp->GetTarget()
   .CreateBreakpoint(symbol_address, internal, hardware)
   .get();
   breakpoint->SetCallback(InstrumentationRuntimeASan::NotifyBreakpointHit, 
this,
-  true);
+  sync);
   breakpoint->SetBreakpointKind("address-sanitizer-report");
   SetBreakpointID(breakpoint->GetID());
 

diff  --git 
a/lldb/source/Plugins/InstrumentationRuntime/MainThreadChecker/InstrumentationRuntimeMainThreadChecker.cpp
 
b/lldb/source/Plugins/InstrumentationRuntime/MainThreadChecker/InstrumentationRuntimeMainThreadChecker.cpp
index a5c23615309d5..e22cc86116ce5 100644
--- 
a/lldb/source/Plugins/InstrumentationRuntime/MainThreadChecker/InstrumentationRuntimeMainThreadChecker.cpp
+++ 
b/lldb/source/Plugins/InstrumentationRuntime/MainThreadChecker/InstrumentationRuntimeMainThreadChecker.cpp
@@ -214,8 +214,9 @@ void InstrumentationRuntimeMainThreadChecker::Activate() {
   .CreateBreakpoint(symbol_address, /*internal=*/true,
 /*hardware=*/false)
   .get();
+  const bool sync = false;
   breakpoint->SetCallback(
-  InstrumentationRuntimeMainThreadChecker::NotifyBreakpointHit, this, 
true);
+  InstrumentationRuntimeMainThreadChecker::NotifyBreakpointHit, this, 
sync);
   breakpoint->SetBreakpointKind("main-thread-checker-report");
   SetBreakpointID(breakpoint->GetID());
 

diff  --git 
a/lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
 
b/lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
index 910992c48a7dc..425b0baa453f8 100644
--- 
a/lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
+++ 
b/lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp
@@ -915,14 +915,15 @@ void InstrumentationRuntimeTSan::Activate() {
   if (symbol_address == LLDB_INVALID_ADDRESS)
 return;
 
-  bool internal = true;
-  bool hardware = 

[Lldb-commits] [lldb] 670cac7 - Rename a duplicate test, also give the test class a useful name.

2022-09-27 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-27T12:38:22-07:00
New Revision: 670cac72804bbeb91fd0653de621aa03f70600e3

URL: 
https://github.com/llvm/llvm-project/commit/670cac72804bbeb91fd0653de621aa03f70600e3
DIFF: 
https://github.com/llvm/llvm-project/commit/670cac72804bbeb91fd0653de621aa03f70600e3.diff

LOG: Rename a duplicate test, also give the test class a useful name.

Added: 

lldb/test/API/lang/cpp/function-ref-qualifiers/TestCppFunctionRefQualifiers.py

Modified: 
lldb/test/API/lang/cpp/function-qualifiers/TestCppFunctionQualifiers.py

Removed: 
lldb/test/API/lang/cpp/function-ref-qualifiers/TestCppFunctionQualifiers.py



diff  --git 
a/lldb/test/API/lang/cpp/function-qualifiers/TestCppFunctionQualifiers.py 
b/lldb/test/API/lang/cpp/function-qualifiers/TestCppFunctionQualifiers.py
index bc3b6d156046d..13ef2fc30330b 100644
--- a/lldb/test/API/lang/cpp/function-qualifiers/TestCppFunctionQualifiers.py
+++ b/lldb/test/API/lang/cpp/function-qualifiers/TestCppFunctionQualifiers.py
@@ -3,7 +3,7 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
-class TestCase(TestBase):
+class TestFunctionQualifiers(TestBase):
 
 def test(self):
 self.build()

diff  --git 
a/lldb/test/API/lang/cpp/function-ref-qualifiers/TestCppFunctionQualifiers.py 
b/lldb/test/API/lang/cpp/function-ref-qualifiers/TestCppFunctionRefQualifiers.py
similarity index 96%
rename from 
lldb/test/API/lang/cpp/function-ref-qualifiers/TestCppFunctionQualifiers.py
rename to 
lldb/test/API/lang/cpp/function-ref-qualifiers/TestCppFunctionRefQualifiers.py
index 0016ede4937e2..152e8c94a7fc7 100644
--- 
a/lldb/test/API/lang/cpp/function-ref-qualifiers/TestCppFunctionQualifiers.py
+++ 
b/lldb/test/API/lang/cpp/function-ref-qualifiers/TestCppFunctionRefQualifiers.py
@@ -9,7 +9,7 @@
 from lldbsuite.test.lldbtest import *
 from lldbsuite.test import lldbutil
 
-class TestCase(TestBase):
+class TestFunctionRefQualifiers(TestBase):
 
 def test(self):
 self.build()



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D133876: [lldb][tests][NFC] Move C++ gmodules tests into new gmodules/ subdirectory

2022-09-16 Thread Jim Ingham via lldb-commits
To be more specific, the problem is that there used to be a directory in the 
test suite called gmodules-template and Michael moved it to gmodules/template 
to better organize the tests.  But our rule for making a test name from 
subdirectories is to replace the "/" with a "-" so these two ended up being the 
same test name, which is an error.  

Michael's patch properly moved gmodules-template to gmodules/template so there 
actually shouldn't be a conflict.  But because python insists on sticking these 
__pycache__ directories alongside the test files git won't actually remove the 
directory on update, and thus until you either manually remove the 
gmodules-template directory or do a fresh checkout you'll get this error.

Is there a way to get the testsuite runs not to put these cache files into the 
source tree?  Running the testsuite really shouldn't be changing the source 
tree...  Or if we can't get it to stop that, is there a "git pull" that will 
clean up anything not actually in the repo?  I don't think we ever actually 
want to preserve anything of that sort from run to run.

Jim


> On Sep 16, 2022, at 3:24 PM, Michael Buch via Phabricator via lldb-commits 
>  wrote:
> 
> Michael137 added a comment.
> 
> In D133876#3796847 , @dyung wrote:
> 
>> @Michael137, your change is causing cmake to fail on one of our bots:
>> 
>> https://lab.llvm.org/buildbot/#/builders/217/builds/11819
>> 
>>  CMake Error at cmake/modules/AddLLVM.cmake:1867 (add_custom_target):
>>add_custom_target cannot create target
>>"check-lldb-api-lang-cpp-gmodules-templates" because another target with
>>the same name already exists.  The existing target is a custom target
>>created in source directory
>>
>> "/home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/test/API".
>>See documentation for policy CMP0002 for more details.
>>  Call Stack (most recent call first):
>>cmake/modules/AddLLVM.cmake:1980 (add_lit_target)
>>
>> /home/buildbot/buildbot-root/cross-project-tests-sie-ubuntu/llvm-project/lldb/test/API/CMakeLists.txt:4
>>  (add_lit_testsuites)
>> 
>> Can you take a look?
> 
> Here I'm just renaming a directory. @dyung I think this might have to do with 
> a stale `__pycache__` directory in the test directory. Can you force a fresh 
> checkout on the build bot and restart?
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D133876/new/
> 
> https://reviews.llvm.org/D133876
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] f3d0bda - Revert "Revert "Be more careful to maintain quoting information when parsing commands.""

2022-09-14 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-14T14:49:51-07:00
New Revision: f3d0bda5344e8429121cb50aba5502c1b399e5cd

URL: 
https://github.com/llvm/llvm-project/commit/f3d0bda5344e8429121cb50aba5502c1b399e5cd
DIFF: 
https://github.com/llvm/llvm-project/commit/f3d0bda5344e8429121cb50aba5502c1b399e5cd.diff

LOG: Revert "Revert "Be more careful to maintain quoting information when 
parsing commands.""

This reverts commit ac05bc0524c66c74278b26742896a4c634c034cf.

I had incorrectly removed one set of checks in the option handling in
Options::ParseAlias because I couldn't see what it is for.  It was a
bit obscure, but it handled the case where you pass "-something=other --"
as the input_line, which caused the built-in "run" alias not to return
the right value for IsDashDashCommand, causing TestHelp.py to fail.

Added: 
lldb/test/API/commands/command/backticks/Makefile
lldb/test/API/commands/command/backticks/TestBackticksInAlias.py
lldb/test/API/commands/command/backticks/main.c

Modified: 
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/Interpreter/CommandAlias.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Interpreter/CommandObject.cpp
lldb/source/Interpreter/Options.cpp
lldb/source/Utility/Args.cpp

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index 0f137a7b3c496..255f50099ebb9 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -239,6 +239,14 @@ class CommandInterpreter : public Broadcaster,
 eCommandTypesAllThem = 0x  //< all commands
   };
 
+  // The CommandAlias and CommandInterpreter both have a hand in 
+  // substituting for alias commands.  They work by writing special tokens
+  // in the template form of the Alias command, and then detecting them when 
the
+  // command is executed.  These are the special tokens:
+  static const char *g_no_argument;
+  static const char *g_need_argument;
+  static const char *g_argument;
+
   CommandInterpreter(Debugger , bool synchronous_execution);
 
   ~CommandInterpreter() override = default;

diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 101921ffc768b..5c058769ff3f9 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -2472,6 +2472,13 @@ def assertSuccess(self, obj, msg=None):
 self.fail(self._formatMessage(msg,
 "'{}' is not success".format(error)))
 
+"""Assert that a command return object is successful"""
+def assertCommandReturn(self, obj, msg=None):
+if not obj.Succeeded():
+error = obj.GetError()
+self.fail(self._formatMessage(msg,
+"'{}' is not success".format(error)))
+
 """Assert two states are equal"""
 def assertState(self, first, second, msg=None):
 if first != second:

diff  --git a/lldb/source/Interpreter/CommandAlias.cpp 
b/lldb/source/Interpreter/CommandAlias.cpp
index d55b3fdd44faf..e36edcac15a59 100644
--- a/lldb/source/Interpreter/CommandAlias.cpp
+++ b/lldb/source/Interpreter/CommandAlias.cpp
@@ -60,11 +60,12 @@ static bool ProcessAliasOptionsArgs(lldb::CommandObjectSP 
_obj_sp,
 
   if (!options_string.empty()) {
 if (cmd_obj_sp->WantsRawCommandString())
-  option_arg_vector->emplace_back("", -1, options_string);
+  option_arg_vector->emplace_back(CommandInterpreter::g_argument, 
+  -1, options_string);
 else {
   for (auto  : args.entries()) {
 if (!entry.ref().empty())
-  option_arg_vector->emplace_back(std::string(""), -1,
+  
option_arg_vector->emplace_back(std::string(CommandInterpreter::g_argument), -1,
   std::string(entry.ref()));
   }
 }
@@ -153,11 +154,12 @@ void CommandAlias::GetAliasExpansion(StreamString 
_string) const {
 
   for (const auto _entry : *options) {
 std::tie(opt, std::ignore, value) = opt_entry;
-if (opt == "") {
+if (opt == CommandInterpreter::g_argument) {
   help_string.Printf(" %s", value.c_str());
 } else {
   help_string.Printf(" %s", opt.c_str());
-  if ((value != "") && (value != " 
CommandAlias::Desugar() {
 return {nullptr, nullptr};
 
   if (underlying->IsAlias()) {
+// FIXME: This doesn't work if the original alias fills a slot in the
+// underlying alias, since this just appends the two lists.
 auto desugared = ((CommandAlias *)underlying.get())->Desugar();
 auto options = GetOptionArguments();
 options->insert(options->begin(), desugared.second->begin(),

diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 

[Lldb-commits] [lldb] ac05bc0 - Revert "Be more careful to maintain quoting information when parsing commands."

2022-09-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-13T14:59:21-07:00
New Revision: ac05bc0524c66c74278b26742896a4c634c034cf

URL: 
https://github.com/llvm/llvm-project/commit/ac05bc0524c66c74278b26742896a4c634c034cf
DIFF: 
https://github.com/llvm/llvm-project/commit/ac05bc0524c66c74278b26742896a4c634c034cf.diff

LOG: Revert "Be more careful to maintain quoting information when parsing 
commands."

This reverts commit 6c089b2af5d8d98f66b27b67f70958f520820a76.

This was causing the test test_help_run_hides_options from TestHelp.py to
fail on Linux and Windows (but the test succeeds on macOS).  The decision
to print option information is determined by 
CommandObjectAlias::IsDashDashCommand
which was changed, but only by replacing an inline string constant with a const 
char *
CommandInterpreter::g_argument which has the same string value.  I can't see 
why this
would fail, I'll have to spin up a vm to see if I can repo there.

Added: 


Modified: 
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/Interpreter/CommandAlias.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Interpreter/CommandObject.cpp
lldb/source/Interpreter/Options.cpp
lldb/source/Utility/Args.cpp

Removed: 
lldb/test/API/commands/command/backticks/Makefile
lldb/test/API/commands/command/backticks/TestBackticksInAlias.py
lldb/test/API/commands/command/backticks/main.c



diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index 71587eed68c9..0f137a7b3c49 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -239,14 +239,6 @@ class CommandInterpreter : public Broadcaster,
 eCommandTypesAllThem = 0x  //< all commands
   };
 
-  // The CommandAlias and CommandInterpreter both have a hand in 
-  // substituting for alias commands.  They work by writing special tokens
-  // in the template form of the Alias command, and then detecting them when 
the
-  // command is executed.  These are the special tokens:
-  static const char * const g_no_argument;
-  static const char * const g_need_argument;
-  static const char * const g_argument;
-
   CommandInterpreter(Debugger , bool synchronous_execution);
 
   ~CommandInterpreter() override = default;

diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 5c058769ff3f..101921ffc768 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -2472,13 +2472,6 @@ def assertSuccess(self, obj, msg=None):
 self.fail(self._formatMessage(msg,
 "'{}' is not success".format(error)))
 
-"""Assert that a command return object is successful"""
-def assertCommandReturn(self, obj, msg=None):
-if not obj.Succeeded():
-error = obj.GetError()
-self.fail(self._formatMessage(msg,
-"'{}' is not success".format(error)))
-
 """Assert two states are equal"""
 def assertState(self, first, second, msg=None):
 if first != second:

diff  --git a/lldb/source/Interpreter/CommandAlias.cpp 
b/lldb/source/Interpreter/CommandAlias.cpp
index e36edcac15a5..d55b3fdd44fa 100644
--- a/lldb/source/Interpreter/CommandAlias.cpp
+++ b/lldb/source/Interpreter/CommandAlias.cpp
@@ -60,12 +60,11 @@ static bool ProcessAliasOptionsArgs(lldb::CommandObjectSP 
_obj_sp,
 
   if (!options_string.empty()) {
 if (cmd_obj_sp->WantsRawCommandString())
-  option_arg_vector->emplace_back(CommandInterpreter::g_argument, 
-  -1, options_string);
+  option_arg_vector->emplace_back("", -1, options_string);
 else {
   for (auto  : args.entries()) {
 if (!entry.ref().empty())
-  
option_arg_vector->emplace_back(std::string(CommandInterpreter::g_argument), -1,
+  option_arg_vector->emplace_back(std::string(""), -1,
   std::string(entry.ref()));
   }
 }
@@ -154,12 +153,11 @@ void CommandAlias::GetAliasExpansion(StreamString 
_string) const {
 
   for (const auto _entry : *options) {
 std::tie(opt, std::ignore, value) = opt_entry;
-if (opt == CommandInterpreter::g_argument) {
+if (opt == "") {
   help_string.Printf(" %s", value.c_str());
 } else {
   help_string.Printf(" %s", opt.c_str());
-  if ((value != CommandInterpreter::g_no_argument) 
-   && (value != CommandInterpreter::g_need_argument)) {
+  if ((value != "") && (value != " 
CommandAlias::Desugar() {
 return {nullptr, nullptr};
 
   if (underlying->IsAlias()) {
-// FIXME: This doesn't work if the original alias fills a slot in the
-// underlying alias, since this just appends the two 

[Lldb-commits] [lldb] a2d0a01 - Revert "constexpr isn't right here."

2022-09-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-13T14:58:53-07:00
New Revision: a2d0a01e3f9941d0d5370890105f70da142f493f

URL: 
https://github.com/llvm/llvm-project/commit/a2d0a01e3f9941d0d5370890105f70da142f493f
DIFF: 
https://github.com/llvm/llvm-project/commit/a2d0a01e3f9941d0d5370890105f70da142f493f.diff

LOG: Revert "constexpr isn't right here."

This didn't help either.

This reverts commit 8433b210839ed655852428ba8b34bb67b191957a.

Added: 


Modified: 
lldb/source/Interpreter/CommandInterpreter.cpp

Removed: 




diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 89878713161b..2218d54e3d97 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -105,9 +105,9 @@ static constexpr const char *InitFileWarning =
 "and\n"
 "accept the security risk.";
 
-const char * const CommandInterpreter::g_no_argument = "";
-const char * const CommandInterpreter::g_need_argument = "";
-const char * const CommandInterpreter::g_argument = "";
+constexpr const char *CommandInterpreter::g_no_argument = "";
+constexpr const char *CommandInterpreter::g_need_argument = "";
+constexpr const char *CommandInterpreter::g_argument = "";
 
 
 #define LLDB_PROPERTIES_interpreter



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 3f23eb6 - Revert "Trying to understand the TestHelp.py failure from 6c089b2."

2022-09-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-13T14:58:27-07:00
New Revision: 3f23eb6591bb1eecae38019e8ab1fdf5e2951ae9

URL: 
https://github.com/llvm/llvm-project/commit/3f23eb6591bb1eecae38019e8ab1fdf5e2951ae9
DIFF: 
https://github.com/llvm/llvm-project/commit/3f23eb6591bb1eecae38019e8ab1fdf5e2951ae9.diff

LOG: Revert "Trying to understand the TestHelp.py failure from 6c089b2."

It didn't help.

This reverts commit 81f8788528886ee611041e1f4ee54eea8bbfa277.

Added: 


Modified: 
lldb/source/Interpreter/CommandAlias.cpp

Removed: 




diff  --git a/lldb/source/Interpreter/CommandAlias.cpp 
b/lldb/source/Interpreter/CommandAlias.cpp
index 80a926ef4d6a..e36edcac15a5 100644
--- a/lldb/source/Interpreter/CommandAlias.cpp
+++ b/lldb/source/Interpreter/CommandAlias.cpp
@@ -180,7 +180,7 @@ bool CommandAlias::IsDashDashCommand() {
 
   for (const auto _entry : *GetOptionArguments()) {
 std::tie(opt, std::ignore, value) = opt_entry;
-if (opt == "" && !value.empty() &&
+if (opt == CommandInterpreter::g_argument && !value.empty() &&
 llvm::StringRef(value).endswith("--")) {
   m_is_dashdash_alias = eLazyBoolYes;
   break;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 81f8788 - Trying to understand the TestHelp.py failure from 6c089b2.

2022-09-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-13T14:09:44-07:00
New Revision: 81f8788528886ee611041e1f4ee54eea8bbfa277

URL: 
https://github.com/llvm/llvm-project/commit/81f8788528886ee611041e1f4ee54eea8bbfa277
DIFF: 
https://github.com/llvm/llvm-project/commit/81f8788528886ee611041e1f4ee54eea8bbfa277.diff

LOG: Trying to understand the TestHelp.py failure from 6c089b2.

Sadly, the test passes on macOS, but fails on Ubuntu & Win.  The
extra option printing is supposed to be suppressed by the return
from CommandObjectAlias::IsDashDashCommand.  That was changed, but just
by replacing an inline string compare with a const string from
CommandInterpreter.  Putting the old version back temporarily to
see if that is really the problem.

Added: 


Modified: 
lldb/source/Interpreter/CommandAlias.cpp

Removed: 




diff  --git a/lldb/source/Interpreter/CommandAlias.cpp 
b/lldb/source/Interpreter/CommandAlias.cpp
index e36edcac15a5..80a926ef4d6a 100644
--- a/lldb/source/Interpreter/CommandAlias.cpp
+++ b/lldb/source/Interpreter/CommandAlias.cpp
@@ -180,7 +180,7 @@ bool CommandAlias::IsDashDashCommand() {
 
   for (const auto _entry : *GetOptionArguments()) {
 std::tie(opt, std::ignore, value) = opt_entry;
-if (opt == CommandInterpreter::g_argument && !value.empty() &&
+if (opt == "" && !value.empty() &&
 llvm::StringRef(value).endswith("--")) {
   m_is_dashdash_alias = eLazyBoolYes;
   break;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 8433b21 - constexpr isn't right here.

2022-09-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-13T13:01:56-07:00
New Revision: 8433b210839ed655852428ba8b34bb67b191957a

URL: 
https://github.com/llvm/llvm-project/commit/8433b210839ed655852428ba8b34bb67b191957a
DIFF: 
https://github.com/llvm/llvm-project/commit/8433b210839ed655852428ba8b34bb67b191957a.diff

LOG: constexpr isn't right here.

Added: 


Modified: 
lldb/source/Interpreter/CommandInterpreter.cpp

Removed: 




diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 2218d54e3d97..89878713161b 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -105,9 +105,9 @@ static constexpr const char *InitFileWarning =
 "and\n"
 "accept the security risk.";
 
-constexpr const char *CommandInterpreter::g_no_argument = "";
-constexpr const char *CommandInterpreter::g_need_argument = "";
-constexpr const char *CommandInterpreter::g_argument = "";
+const char * const CommandInterpreter::g_no_argument = "";
+const char * const CommandInterpreter::g_need_argument = "";
+const char * const CommandInterpreter::g_argument = "";
 
 
 #define LLDB_PROPERTIES_interpreter



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 6c089b2 - Be more careful to maintain quoting information when parsing commands.

2022-09-13 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-13T11:02:47-07:00
New Revision: 6c089b2af5d8d98f66b27b67f70958f520820a76

URL: 
https://github.com/llvm/llvm-project/commit/6c089b2af5d8d98f66b27b67f70958f520820a76
DIFF: 
https://github.com/llvm/llvm-project/commit/6c089b2af5d8d98f66b27b67f70958f520820a76.diff

LOG: Be more careful to maintain quoting information when parsing commands.

This is particularly a problem for alias construction, where you might
want to have a backtick surrounded option in the alias.  Before this
patch:

command alias expression -Z \`argc\` -- argv

for instance would be rendered as:

expression -Z argc -- argv

and would fail to work.

Differential Revision: https://reviews.llvm.org/D133045

Added: 
lldb/test/API/commands/command/backticks/Makefile
lldb/test/API/commands/command/backticks/TestBackticksInAlias.py
lldb/test/API/commands/command/backticks/main.c

Modified: 
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/Interpreter/CommandAlias.cpp
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Interpreter/CommandObject.cpp
lldb/source/Interpreter/Options.cpp
lldb/source/Utility/Args.cpp

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index 0f137a7b3c496..71587eed68c95 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -239,6 +239,14 @@ class CommandInterpreter : public Broadcaster,
 eCommandTypesAllThem = 0x  //< all commands
   };
 
+  // The CommandAlias and CommandInterpreter both have a hand in 
+  // substituting for alias commands.  They work by writing special tokens
+  // in the template form of the Alias command, and then detecting them when 
the
+  // command is executed.  These are the special tokens:
+  static const char * const g_no_argument;
+  static const char * const g_need_argument;
+  static const char * const g_argument;
+
   CommandInterpreter(Debugger , bool synchronous_execution);
 
   ~CommandInterpreter() override = default;

diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 101921ffc768b..5c058769ff3f9 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -2472,6 +2472,13 @@ def assertSuccess(self, obj, msg=None):
 self.fail(self._formatMessage(msg,
 "'{}' is not success".format(error)))
 
+"""Assert that a command return object is successful"""
+def assertCommandReturn(self, obj, msg=None):
+if not obj.Succeeded():
+error = obj.GetError()
+self.fail(self._formatMessage(msg,
+"'{}' is not success".format(error)))
+
 """Assert two states are equal"""
 def assertState(self, first, second, msg=None):
 if first != second:

diff  --git a/lldb/source/Interpreter/CommandAlias.cpp 
b/lldb/source/Interpreter/CommandAlias.cpp
index d55b3fdd44faf..e36edcac15a59 100644
--- a/lldb/source/Interpreter/CommandAlias.cpp
+++ b/lldb/source/Interpreter/CommandAlias.cpp
@@ -60,11 +60,12 @@ static bool ProcessAliasOptionsArgs(lldb::CommandObjectSP 
_obj_sp,
 
   if (!options_string.empty()) {
 if (cmd_obj_sp->WantsRawCommandString())
-  option_arg_vector->emplace_back("", -1, options_string);
+  option_arg_vector->emplace_back(CommandInterpreter::g_argument, 
+  -1, options_string);
 else {
   for (auto  : args.entries()) {
 if (!entry.ref().empty())
-  option_arg_vector->emplace_back(std::string(""), -1,
+  
option_arg_vector->emplace_back(std::string(CommandInterpreter::g_argument), -1,
   std::string(entry.ref()));
   }
 }
@@ -153,11 +154,12 @@ void CommandAlias::GetAliasExpansion(StreamString 
_string) const {
 
   for (const auto _entry : *options) {
 std::tie(opt, std::ignore, value) = opt_entry;
-if (opt == "") {
+if (opt == CommandInterpreter::g_argument) {
   help_string.Printf(" %s", value.c_str());
 } else {
   help_string.Printf(" %s", opt.c_str());
-  if ((value != "") && (value != " 
CommandAlias::Desugar() {
 return {nullptr, nullptr};
 
   if (underlying->IsAlias()) {
+// FIXME: This doesn't work if the original alias fills a slot in the
+// underlying alias, since this just appends the two lists.
 auto desugared = ((CommandAlias *)underlying.get())->Desugar();
 auto options = GetOptionArguments();
 options->insert(options->begin(), desugared.second->begin(),

diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 

[Lldb-commits] [lldb] 9690308 - Fix another place were we suggest lldb.target in a Frame Recognizer.

2022-09-06 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-06T13:24:21-07:00
New Revision: 9690308f78b26df8461f5ac1cb5ba83344254e55

URL: 
https://github.com/llvm/llvm-project/commit/9690308f78b26df8461f5ac1cb5ba83344254e55
DIFF: 
https://github.com/llvm/llvm-project/commit/9690308f78b26df8461f5ac1cb5ba83344254e55.diff

LOG: Fix another place were we suggest lldb.target in a Frame Recognizer.

Added: 


Modified: 
lldb/source/Commands/CommandObjectFrame.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectFrame.cpp 
b/lldb/source/Commands/CommandObjectFrame.cpp
index 23954dd3c9fdc..e5d14d641b8a8 100644
--- a/lldb/source/Commands/CommandObjectFrame.cpp
+++ b/lldb/source/Commands/CommandObjectFrame.cpp
@@ -814,7 +814,8 @@ functions 'read', 'write' and 'close' follows:
 def get_recognized_arguments(self, frame):
   if frame.name in ["read", "write", "close"]:
 fd = frame.EvaluateExpression("$arg1").unsigned
-value = lldb.target.CreateValueFromExpression("fd", "(int)%d" % fd)
+target = frame.thread.process.target
+value = target.CreateValueFromExpression("fd", "(int)%d" % fd)
 return [value]
   return []
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] edea4a3 - You can't use lldb.target in a frame recognizer.

2022-09-06 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-09-06T13:20:48-07:00
New Revision: edea4a349d04972783d74d00af9245768d6b586e

URL: 
https://github.com/llvm/llvm-project/commit/edea4a349d04972783d74d00af9245768d6b586e
DIFF: 
https://github.com/llvm/llvm-project/commit/edea4a349d04972783d74d00af9245768d6b586e.diff

LOG: You can't use lldb.target in a frame recognizer.

Added: 


Modified: 
lldb/docs/use/python-reference.rst

Removed: 




diff  --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index ee3db9ab56d10..9431704902091 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -860,7 +860,8 @@ functions 'read', 'write' and 'close' follows:
 def get_recognized_arguments(self, frame):
   if frame.name in ["read", "write", "close"]:
 fd = frame.EvaluateExpression("$arg1").unsigned
-value = lldb.target.CreateValueFromExpression("fd", "(int)%d" % fd)
+target = frame.thread.process.target
+value = target.CreateValueFromExpression("fd", "(int)%d" % fd)
 return [value]
   return []
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] a2670b9 - Fix a bug in lldb-dotest that was uncovered by setting no value for dotest_args_str.

2022-08-31 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-08-31T18:00:18-07:00
New Revision: a2670b92a2542a9bb889db81ba0cf5a21b3240ee

URL: 
https://github.com/llvm/llvm-project/commit/a2670b92a2542a9bb889db81ba0cf5a21b3240ee
DIFF: 
https://github.com/llvm/llvm-project/commit/a2670b92a2542a9bb889db81ba0cf5a21b3240ee.diff

LOG: Fix a bug in lldb-dotest that was uncovered by setting no value for 
dotest_args_str.
We were splitting the string, and adding that array to cmd.  But split generated
[''] which shows up later on as an empty "test directory search path".  That got
extended to the CWD + "" which generally doesn't have any tests, so

lldb-dotest -p SomeRealTest.py

would fail with a no matching tests error.

Differential Revision: https://reviews.llvm.org/D133075

Added: 


Modified: 
lldb/utils/lldb-dotest/lldb-dotest.in

Removed: 




diff  --git a/lldb/utils/lldb-dotest/lldb-dotest.in 
b/lldb/utils/lldb-dotest/lldb-dotest.in
index f6b5e0d01dcfa..896cc13913539 100755
--- a/lldb/utils/lldb-dotest/lldb-dotest.in
+++ b/lldb/utils/lldb-dotest/lldb-dotest.in
@@ -16,7 +16,11 @@ llvm_tools_dir = "@LLVM_TOOLS_DIR_CONFIGURED@"
 
 if __name__ == '__main__':
 wrapper_args = sys.argv[1:]
-dotest_args = dotest_args_str.split(';')
+dotest_args = []
+# split on an empty string will produce [''] and if you
+# add that to the command, it will be treated as a directory...
+if len(dotest_args_str) > 0:
+dotest_args = dotest_args_str.split(';')
 # Build dotest.py command.
 cmd = [sys.executable, dotest_path]
 cmd.extend(['--arch', arch])



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 5ad6ed0 - Change the meaning of a UUID with all zeros for data.

2022-08-30 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-08-30T10:17:58-07:00
New Revision: 5ad6ed0e5519ed26442cd0a21cdb07f5c53b854e

URL: 
https://github.com/llvm/llvm-project/commit/5ad6ed0e5519ed26442cd0a21cdb07f5c53b854e
DIFF: 
https://github.com/llvm/llvm-project/commit/5ad6ed0e5519ed26442cd0a21cdb07f5c53b854e.diff

LOG: Change the meaning of a UUID with all zeros for data.

Previously, depending on how you constructed a UUID from data or a
StringRef, an input value of all zeros was valid (e.g. setFromData)
or not (e.g. setFromOptionalData).  Since there was no way to tell
which interpretation to use, it was done somewhat inconsistently.
This standardizes the meaning of a UUID of all zeros to Not Valid,
and removes all the Optional methods and their uses, as well as the
static factories that supported them.

Differential Revision: https://reviews.llvm.org/D132191

Added: 


Modified: 
lldb/include/lldb/Utility/UUID.h
lldb/source/API/SBModuleSpec.cpp
lldb/source/Core/DataFileCache.cpp
lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm

lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.cpp
lldb/source/Plugins/ObjectFile/Breakpad/BreakpadRecords.cpp
lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
lldb/source/Plugins/ObjectFile/PDB/ObjectFilePDB.cpp
lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
lldb/source/Plugins/Process/minidump/MinidumpParser.cpp
lldb/source/Utility/UUID.cpp
lldb/unittests/ObjectFile/Breakpad/BreakpadRecordsTest.cpp
lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
lldb/unittests/SymbolFile/DWARF/DWARFIndexCachingTest.cpp
lldb/unittests/Utility/UUIDTest.cpp

Removed: 




diff  --git a/lldb/include/lldb/Utility/UUID.h 
b/lldb/include/lldb/Utility/UUID.h
index 1c7c04758da0..56aa3fa8450b 100644
--- a/lldb/include/lldb/Utility/UUID.h
+++ b/lldb/include/lldb/Utility/UUID.h
@@ -21,8 +21,18 @@ namespace lldb_private {
   class Stream;
 
 class UUID {
+  // Represents UUID's of various sizes.  In all cases, a uuid of all zeros is
+  // treated as an "Invalid UUID" marker, and the UUID created from such data
+  // will return false for IsValid.
 public:
   UUID() = default;
+  
+  /// Creates a uuid from the data pointed to by the bytes argument.
+  UUID(llvm::ArrayRef bytes) : m_bytes(bytes.begin(), bytes.end()) {
+if (llvm::all_of(m_bytes, [](uint8_t b) { return b == 0; })) {
+  Clear();
+   }
+  }
 
   // Reference:
   // 
https://crashpad.chromium.org/doxygen/structcrashpad_1_1CodeViewRecordPDB70.html
@@ -38,35 +48,15 @@ class UUID {
   };
 
   /// Create a UUID from CvRecordPdb70.
-  static UUID fromCvRecord(CvRecordPdb70 debug_info);
-
-  /// Creates a UUID from the data pointed to by the bytes argument. No special
-  /// significance is attached to any of the values.
-  static UUID fromData(const void *bytes, uint32_t num_bytes) {
-if (bytes)
-  return fromData({reinterpret_cast(bytes), num_bytes});
-return UUID();
-  }
-
-  /// Creates a uuid from the data pointed to by the bytes argument. No special
-  /// significance is attached to any of the values.
-  static UUID fromData(llvm::ArrayRef bytes) { return UUID(bytes); }
-
-  /// Creates a UUID from the data pointed to by the bytes argument. Data
-  /// consisting purely of zero bytes is treated as an invalid UUID.
-  static UUID fromOptionalData(const void *bytes, uint32_t num_bytes) {
-if (bytes)
-  return fromOptionalData(
-  {reinterpret_cast(bytes), num_bytes});
-return UUID();
-  }
-
-  /// Creates a UUID from the data pointed to by the bytes argument. Data
-  /// consisting purely of zero bytes is treated as an invalid UUID.
-  static UUID fromOptionalData(llvm::ArrayRef bytes) {
-if (llvm::all_of(bytes, [](uint8_t b) { return b == 0; }))
-  return UUID();
-return UUID(bytes);
+  UUID(CvRecordPdb70 debug_info);
+
+  /// Creates a UUID from the data pointed to by the bytes argument. 
+  UUID(const void *bytes, uint32_t num_bytes) {
+if (!bytes)
+  return;
+*this 
+= UUID(llvm::ArrayRef(reinterpret_cast(bytes), 
+   num_bytes));
   }
 
   void Clear() { m_bytes.clear(); }
@@ -77,15 +67,11 @@ class UUID {
 
   explicit operator bool() const { return IsValid(); }
   bool IsValid() const { return !m_bytes.empty(); }
-
+  
   std::string GetAsString(llvm::StringRef separator = "-") const;
 
   bool SetFromStringRef(llvm::StringRef str);
 
-  // Same as SetFromStringRef, but if the resultant UUID is all 0 bytes, set 
the
-  // UUID to invalid.
-  bool SetFromOptionalStringRef(llvm::StringRef str);
-
   /// Decode as many UUID bytes as possible from the C string 

Re: [Lldb-commits] [PATCH] D132624: [LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

2022-08-26 Thread Jim Ingham via lldb-commits


> On Aug 26, 2022, at 5:08 PM, Adrian Vogelsgesang 
>  wrote:
> 
> Thank you for that hint, Jim! This infrastructure indeed looks very 
> interesting for my use case.
> I will most likely use the HistoryThread class to represent the backtrace of 
> the logical coroutine threads.
> 
> Is my understanding correct, that `GetExtendedBacktraceThreads` only allows 
> me to append additional stack trace frames to existing, physical threads, 
> though? I want to expose completely new threads instead. In a sense, I want 
> to display each pending request inside my asynchronous multiplexer as its own 
> thread, such that I can see not only the requests which an OS-level thread is 
> currently working on, but also the onse which are currently queued/not yet 
> processed/blocked on IO

I don't know how the std::coroutine stuff works...  In what sense is a "pending 
request" a Thread?  Isn't it a bunch of state and a function pointer that's 
waiting around to be run?  In which case, maybe we need another entity to 
describe those?  This is something that we don't handle at all in the "dispatch 
queue" interface in lldb.  We don't have a way to say "show me all queued but 
not being serviced" work.  When we get around to supporting that we'd need to 
add something to describe "queue-able work".

OTOH, if you are really dealing something like a scheduler so that the "pending 
work" is threads that were moved off of "system threads" and left in memory 
till they are re-enqueued, then you do need a way to tell lldb about those 
threads.  There are two ways to do that in lldb.  One is the OperatingSystem 
Plugin, which requires only that you provide a "Register Context's" for threads 
that you know about but the system doesn't.  The stack pointer in the context 
you return should point to the stored stack, and then lldb will do the work of 
producing the rest of the stack frame for that thread.  The other way is using 
the ScriptedProcess feature, where you can just make up threads and their stack 
frames out of whole cloth.  If your thread is still backed by the stack memory 
it was using, then the OperatingSystem plugin way is the easiest way to go for 
this.

Jim

> 
> On Fri, Aug 26, 2022 at 6:38 PM Jim Ingham  > wrote:
>> 
>> 
>> > On Aug 26, 2022, at 7:05 AM, Adrian Vogelsgesang via Phabricator via 
>> > lldb-commits > > > wrote:
>> > 
>> > avogelsgesang added a comment.
>> > 
>> >> I don't know much about coroutines, but it seems like your goal is to 
>> >> format them like a linked list
>> > 
>> > actually, my preferred goal would be to show them as a logical, user-level 
>> > thread. Such that you can type
>> > 
>> >  thread backtrace cxxcoro:0xb2a0
>> > 
>> > to get the backtrace of the logical coroutine thread routed at the 
>> > coroutine at address `0xb2a0`, or maybe even
>> > 
>> >  thread backtrace cxxcoro:hdl
>> > 
>> > where `hdl` is evaluated as an expression to identify the coroutine handle 
>> > from where to dump the backtrace.
>> > 
>> > Also, it would be neat if those logical threads show up in `thread list`...
>> > 
>> > But it seems there is currently no infrastructure yet in LLDB for logical 
>> > threads provided by `LanguageRuntime` plugins.
>> > 
>> > I guess at some point, I will write an RFC about that on discourse. But 
>> > before that, I will first do some more exploration on how LLDB works and I 
>> > will first grab the low-hanging fruits (like a data formatter for 
>> > `std::coroutine_handle` and patching LLVM to emit the necessary debug info)
>> 
>> lldb has the notion of "extended backtrace threads" - backed by lldb's 
>> "History" threads - that it uses in a similar circumstance handling Darwin 
>> dispatch queues.  If you have a thread that is serving a Darwin "dispatch 
>> queue" SBThread.GetExtendedBacktraceThreads will return the backtrace of the 
>> thread that enqueued the work, at the point where the enqueuing is done.  I 
>> bet you could make the same setup work for these coroutines.
>> 
>> Jim
>> 
>> 
>> > 
>> > 
>> > Repository:
>> >  rG LLVM Github Monorepo
>> > 
>> > CHANGES SINCE LAST ACTION
>> >  https://reviews.llvm.org/D132624/new/
>> > 
>> > https://reviews.llvm.org/D132624
>> > 
>> > ___
>> > lldb-commits mailing list
>> > lldb-commits@lists.llvm.org 
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>> 

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D132624: [LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

2022-08-26 Thread Jim Ingham via lldb-commits


> On Aug 26, 2022, at 7:05 AM, Adrian Vogelsgesang via Phabricator via 
> lldb-commits  wrote:
> 
> avogelsgesang added a comment.
> 
>> I don't know much about coroutines, but it seems like your goal is to format 
>> them like a linked list
> 
> actually, my preferred goal would be to show them as a logical, user-level 
> thread. Such that you can type
> 
>  thread backtrace cxxcoro:0xb2a0
> 
> to get the backtrace of the logical coroutine thread routed at the coroutine 
> at address `0xb2a0`, or maybe even
> 
>  thread backtrace cxxcoro:hdl
> 
> where `hdl` is evaluated as an expression to identify the coroutine handle 
> from where to dump the backtrace.
> 
> Also, it would be neat if those logical threads show up in `thread list`...
> 
> But it seems there is currently no infrastructure yet in LLDB for logical 
> threads provided by `LanguageRuntime` plugins.
> 
> I guess at some point, I will write an RFC about that on discourse. But 
> before that, I will first do some more exploration on how LLDB works and I 
> will first grab the low-hanging fruits (like a data formatter for 
> `std::coroutine_handle` and patching LLVM to emit the necessary debug info)

lldb has the notion of "extended backtrace threads" - backed by lldb's 
"History" threads - that it uses in a similar circumstance handling Darwin 
dispatch queues.  If you have a thread that is serving a Darwin "dispatch 
queue" SBThread.GetExtendedBacktraceThreads will return the backtrace of the 
thread that enqueued the work, at the point where the enqueuing is done.  I bet 
you could make the same setup work for these coroutines.

Jim


> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D132624/new/
> 
> https://reviews.llvm.org/D132624
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D132624: [LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

2022-08-25 Thread Jim Ingham via lldb-commits


> On Aug 25, 2022, at 8:11 AM, Pavel Labath via Phabricator via lldb-commits 
>  wrote:
> 
> labath added a comment.
> 
> In D132624#3748434 , @avogelsgesang 
> wrote:
> 
>>> The only concern is that if it would be not so easy to read if there are 
>>> too many levels? (Consider the 30levels example in D132451 
>>> ). If it would be better to print ... at 
>>> certain level? Or this is already handled by lldb?
>> 
>> Agree, it would be better to limit the printing at some point. However, 
>> afaict, limiting the depth to which children are expanded cannot be done 
>> from inside the data formatter/synthetic children frontend. I am not sure if 
>> lldb already has a separate mechanism in place to limit printing in this 
>> case. If it does not, I think it makes sense to add it, but that would be a 
>> separate commit
> 
> The best (I think) mechanism we have is the "pointer depth" limit (defaulting 
> to 1). It works fine on regular objects, but requires some care with 
> synthetic children. The fact that it does not kick in here leads me to 
> believe that the data formatter is creating the synthetic children as non 
> pointer objects (e.g. by automatically dereferencing any nested pointers), 
> even though the structures clearly contain some pointers inside. That is a 
> problem. Not only it creates excessively large outputs, it can even cause 
> lldb to hang (looping endlessly while trying to print "all" children) if the 
> data structures it is trying to print are circular (e.g. due to corruption).

There are actually two separate controls for the depth of child traversal:

(lldb) help v
...
   -D  ( --depth  )
Set the max recurse depth when dumping aggregate types (default is 
infinity).
...
   -P  ( --ptr-depth  )
The number of pointers to be traversed when dumping values (default 
is zero).

There have to be two, because aggregate types can't have cycles, so it's safe 
to set those to a high value, but pointer following can lead to cycles and we 
don't currently do cycle detection so you have to be more careful with this 
setting.

Jim


> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D132624/new/
> 
> https://reviews.llvm.org/D132624
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 3372284 - Use a SmallPtrSet rather than a SmallVector in ClusterManager.

2022-08-18 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-08-18T09:34:28-07:00
New Revision: 33722848fcb5b569ab3a388cae15f31acf9a9c5e

URL: 
https://github.com/llvm/llvm-project/commit/33722848fcb5b569ab3a388cae15f31acf9a9c5e
DIFF: 
https://github.com/llvm/llvm-project/commit/33722848fcb5b569ab3a388cae15f31acf9a9c5e.diff

LOG: Use a SmallPtrSet rather than a SmallVector in ClusterManager.

The m_objects store in this class is only used to check whether
this ClusterManager already owns this pointer.  With a SmallVector
the is_contained call was non-linear in number of children, and for
instance printing all the elements of a 16M element std::vector
didn't complete in the time I was willing to wait for it (hours).

Since we are only doing insert & contains, some kind of set is a
better data structure.  In this patch I used SmallPtrSet.  With
that, the same array prints out in 30 seconds.  I also tried a
std::unordered_set but that was slightly slower and used a fair bit
more memory.

Other than performance, this is NFC.

Differential Revision: https://reviews.llvm.org/D131996

Added: 


Modified: 
lldb/include/lldb/Utility/SharedCluster.h

Removed: 




diff  --git a/lldb/include/lldb/Utility/SharedCluster.h 
b/lldb/include/lldb/Utility/SharedCluster.h
index b3f41dbaa64b0..9f7aa92420ed0 100644
--- a/lldb/include/lldb/Utility/SharedCluster.h
+++ b/lldb/include/lldb/Utility/SharedCluster.h
@@ -11,7 +11,7 @@
 
 #include "lldb/Utility/LLDBAssert.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/SmallPtrSet.h"
 
 #include 
 #include 
@@ -32,15 +32,15 @@ class ClusterManager : public 
std::enable_shared_from_this> {
 
   void ManageObject(T *new_object) {
 std::lock_guard guard(m_mutex);
-assert(!llvm::is_contained(m_objects, new_object) &&
-   "ManageObject called twice for the same object?");
-m_objects.push_back(new_object);
+auto ret = m_objects.insert(new_object);
+assert(ret.second && "ManageObject called twice for the same object?");
   }
 
   std::shared_ptr GetSharedPointer(T *desired_object) {
 std::lock_guard guard(m_mutex);
 auto this_sp = this->shared_from_this();
-if (!llvm::is_contained(m_objects, desired_object)) {
+size_t count =  m_objects.count(desired_object);
+if (count == 0) {
   lldbassert(false && "object not found in shared cluster when expected");
   desired_object = nullptr;
 }
@@ -49,8 +49,14 @@ class ClusterManager : public 
std::enable_shared_from_this> {
 
 private:
   ClusterManager() : m_objects() {}
-
-  llvm::SmallVector m_objects;
+  // The cluster manager is used primarily to manage the
+  // children of root ValueObjects. So it will always have
+  // one element - the root.  Pointers will often have dynamic
+  // values, so having 2 entries is pretty common.  It's also
+  // pretty common to have small (2,3) structs, so setting the
+  // static size to 4 will cover those cases with no allocations
+  // w/o wasting too much space.
+  llvm::SmallPtrSet m_objects;
   std::mutex m_mutex;
 };
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 36a461b - @skipIfAsan for the other long test in TestMemoryRegion.py

2022-08-09 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-08-09T14:55:20-07:00
New Revision: 36a461b8c2a2df47a59789e92908a1275aa5fc30

URL: 
https://github.com/llvm/llvm-project/commit/36a461b8c2a2df47a59789e92908a1275aa5fc30
DIFF: 
https://github.com/llvm/llvm-project/commit/36a461b8c2a2df47a59789e92908a1275aa5fc30.diff

LOG: @skipIfAsan for the other long test in TestMemoryRegion.py

These two tests were each of them too long when running under ASAN,
so we have to skip both to get a clean ASAN bot run.

Added: 


Modified: 
lldb/test/API/functionalities/memory-region/TestMemoryRegion.py

Removed: 




diff  --git a/lldb/test/API/functionalities/memory-region/TestMemoryRegion.py 
b/lldb/test/API/functionalities/memory-region/TestMemoryRegion.py
index 50d64de5b754..66e75e0905ae 100644
--- a/lldb/test/API/functionalities/memory-region/TestMemoryRegion.py
+++ b/lldb/test/API/functionalities/memory-region/TestMemoryRegion.py
@@ -37,8 +37,8 @@ def setup_program(self):
 
 self.runCmd("run", RUN_SUCCEEDED)
 
-# This test builds a large result string in such a way that when run
-# under ASAN the test always times out.  Most of the time is in the asan
+# This test and the next build a large result string in such a way that
+# when run under ASAN the test always times out.  Most of the time is in 
the asan
 # checker under PyUnicode_Append.
 # This seems to be a worst-case scenario for ASAN performance.
 @skipIfAsan
@@ -93,6 +93,7 @@ def test_command(self):
 self.assertTrue(result.Succeeded())
 self.assertEqual(result.GetOutput(), all_regions)
 
+@skipIfAsan
 def test_no_overlapping_regions(self):
 # In the past on Windows we were recording AllocationBase as the base 
address
 # of the current region, not BaseAddress. So if a range of pages was 
split



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 0c86fbb - The memory region tests have been consistently timing on the ASAN

2022-08-09 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-08-09T12:52:18-07:00
New Revision: 0c86fbb557a63d2e9cc2e1a82feb38fe11ecbcdd

URL: 
https://github.com/llvm/llvm-project/commit/0c86fbb557a63d2e9cc2e1a82feb38fe11ecbcdd
DIFF: 
https://github.com/llvm/llvm-project/commit/0c86fbb557a63d2e9cc2e1a82feb38fe11ecbcdd.diff

LOG: The memory region tests have been consistently timing on the ASAN
bot.  This happens because they are building a long result into
a Python string, and the asan checker is making that very slow.

The last two tests here are both slow, but the 'test_command' is the
really slow one.  I'm going to start disabling just that one and see
if that gets the ASAN bots clean.

Added: 


Modified: 
lldb/test/API/functionalities/memory-region/TestMemoryRegion.py

Removed: 




diff  --git a/lldb/test/API/functionalities/memory-region/TestMemoryRegion.py 
b/lldb/test/API/functionalities/memory-region/TestMemoryRegion.py
index 3ea4a75ec9b9c..50d64de5b7543 100644
--- a/lldb/test/API/functionalities/memory-region/TestMemoryRegion.py
+++ b/lldb/test/API/functionalities/memory-region/TestMemoryRegion.py
@@ -37,6 +37,11 @@ def setup_program(self):
 
 self.runCmd("run", RUN_SUCCEEDED)
 
+# This test builds a large result string in such a way that when run
+# under ASAN the test always times out.  Most of the time is in the asan
+# checker under PyUnicode_Append.
+# This seems to be a worst-case scenario for ASAN performance.
+@skipIfAsan
 def test_command(self):
 self.setup_program()
 
@@ -119,4 +124,4 @@ def test_no_overlapping_regions(self):
 "Unexpected overlapping memory region found.")
 
 previous_base = region_base
-previous_end = region_end
\ No newline at end of file
+previous_end = region_end



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 0948f1c - Reapply the commits to enable accurate hit-count detection for watchpoints.

2022-08-05 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-08-05T11:01:27-07:00
New Revision: 0948f1cf8177e378bdea2239b8c3ffb9db31f9ad

URL: 
https://github.com/llvm/llvm-project/commit/0948f1cf8177e378bdea2239b8c3ffb9db31f9ad
DIFF: 
https://github.com/llvm/llvm-project/commit/0948f1cf8177e378bdea2239b8c3ffb9db31f9ad.diff

LOG: Reapply the commits to enable accurate hit-count detection for watchpoints.

This commit combines the initial commit (7c240de609af), a fix for x86_64 Linux
(3a0581501e76) and a fix for thinko in a last minute rewrite that I really
should have run the testsuite on.

Also, make sure that all the "I need to step over watchpoint" plans execute
before we call a public stop.  Otherwise, e.g. if you have N watchpoints and
a Signal, the signal stop info will get us to stop with the watchpoints in a
half-done state.

Differential Revision: https://reviews.llvm.org/D130674

Added: 


Modified: 
lldb/include/lldb/Breakpoint/Watchpoint.h
lldb/include/lldb/Target/StopInfo.h
lldb/include/lldb/Target/Thread.h
lldb/include/lldb/Target/ThreadPlan.h
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Target/StopInfo.cpp
lldb/source/Target/Thread.cpp
lldb/source/Target/ThreadList.cpp

lldb/test/API/commands/watchpoints/watchpoint_commands/condition/TestWatchpointConditionCmd.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentManyWatchpoints.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentNWatchNBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalNWatchNBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatch.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointThreads.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py

Removed: 




diff  --git a/lldb/include/lldb/Breakpoint/Watchpoint.h 
b/lldb/include/lldb/Breakpoint/Watchpoint.h
index 41b723a66b6a3..a5a72e3ad5a1b 100644
--- a/lldb/include/lldb/Breakpoint/Watchpoint.h
+++ b/lldb/include/lldb/Breakpoint/Watchpoint.h
@@ -75,7 +75,7 @@ class Watchpoint : public 
std::enable_shared_from_this,
   bool IsHardware() const override;
 
   bool ShouldStop(StoppointCallbackContext *context) override;
-
+  
   bool WatchpointRead() const;
   bool WatchpointWrite() const;
   uint32_t GetIgnoreCount() const;
@@ -157,12 +157,15 @@ class Watchpoint : public 
std::enable_shared_from_this,
 private:
   friend class Target;
   friend class WatchpointList;
+  friend class StopInfoWatchpoint; // This needs to call UndoHitCount()
 
   void ResetHistoricValues() {
 m_old_value_sp.reset();
 m_new_value_sp.reset();
   }
 
+  void UndoHitCount() { m_hit_counter.Decrement(); }
+
   Target _target;
   bool m_enabled;   // Is this watchpoint enabled
   bool m_is_hardware;   // Is this a hardware watchpoint

diff  --git a/lldb/include/lldb/Target/StopInfo.h 
b/lldb/include/lldb/Target/StopInfo.h
index cdb906dcd7ede..9527a6ea553e3 100644
--- a/lldb/include/lldb/Target/StopInfo.h
+++ b/lldb/include/lldb/Target/StopInfo.h
@@ -17,7 +17,7 @@
 
 namespace lldb_private {
 
-class StopInfo {
+class StopInfo : public std::enable_shared_from_this {
   friend class Process::ProcessEventData;
   friend class ThreadPlanBase;
 

diff  --git a/lldb/include/lldb/Target/Thread.h 
b/lldb/include/lldb/Target/Thread.h
index f5f024434c8ee..efe82721a04e3 100644
--- a/lldb/include/lldb/Target/Thread.h
+++ b/lldb/include/lldb/Target/Thread.h
@@ -240,6 +240,7 @@ class Thread : public std::enable_shared_from_this,
   // this just calls through to the ThreadSpec's ThreadPassesBasicTests method.
   virtual bool MatchesSpec(const ThreadSpec *spec);
 
+  // Get the current public stop info, calculating it if necessary.
   lldb::StopInfoSP GetStopInfo();
 
   lldb::StopReason GetStopReason();
@@ -1121,7 +1122,7 @@ class Thread : public 
std::enable_shared_from_this,
   // "checkpointed and restored" stop info, so if it is still around it is
   // right even if you have not calculated this yourself, or if it disagrees
   // with what you might have calculated.
-  virtual lldb::StopInfoSP GetPrivateStopInfo();
+  virtual lldb::StopInfoSP GetPrivateStopInfo(bool calculate = true);
 
   // Calculate the stop info that will be shown to lldb clients.  For instance,
   // a "step out" 

[Lldb-commits] [lldb] b06da9c - Remove the check for eStateConnected in remote testing sessions.

2022-08-04 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-08-04T09:19:55-07:00
New Revision: b06da9c18390f84950e1d8f70ef2bb0efb433075

URL: 
https://github.com/llvm/llvm-project/commit/b06da9c18390f84950e1d8f70ef2bb0efb433075
DIFF: 
https://github.com/llvm/llvm-project/commit/b06da9c18390f84950e1d8f70ef2bb0efb433075.diff

LOG: Remove the check for eStateConnected in remote testing sessions.

This check is clearly incorrect, there's no way you should have an
eStateConnected event left on the queue if you've already launched
and hit a breakpoint in the program.  This check fails running remotely
on Darwin systems and on one remote Linux platform.  And if we do
find this failing somewhere, we should fix the bogus eStateConnected,
not the test.

Added: 


Modified: 
lldb/test/API/functionalities/signal/TestSendSignal.py

Removed: 




diff  --git a/lldb/test/API/functionalities/signal/TestSendSignal.py 
b/lldb/test/API/functionalities/signal/TestSendSignal.py
index 5808ca17e566c..be74f00aa10a3 100644
--- a/lldb/test/API/functionalities/signal/TestSendSignal.py
+++ b/lldb/test/API/functionalities/signal/TestSendSignal.py
@@ -70,10 +70,6 @@ def test_with_run_command(self):
 # Now continue:
 process.Continue()
 
-# If running remote test, there should be a connected event
-if lldb.remote_platform:
-self.match_state(process_listener, lldb.eStateConnected)
-
 self.match_state(process_listener, lldb.eStateRunning)
 
 # Now signal the process, and make sure it stops:



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 27893ff - Call WatchpointList::RemoveAll in Target::Destroy.

2022-07-27 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-07-27T15:15:05-07:00
New Revision: 27893ff1ad750d9828ca3a774ba9f0029c16149f

URL: 
https://github.com/llvm/llvm-project/commit/27893ff1ad750d9828ca3a774ba9f0029c16149f
DIFF: 
https://github.com/llvm/llvm-project/commit/27893ff1ad750d9828ca3a774ba9f0029c16149f.diff

LOG: Call WatchpointList::RemoveAll in Target::Destroy.

I noticed that the test TestSetWatchpoint.py was failing every so often
on macOS.  The failure was in the last assert, that after destroying the
SBTarget containing it, the SBWatchpoint was still saying it was valid.

IsValid in this case just meant the watchpoint weak pointer could be turned
into a shared pointer.  The watchpoint shared pointers have two strong 
references
in general, one to the "Target::m_last_created_watchpoint", and one in the
Target::m_watchpoint_list.  Target::Destroy reset the last created watchpoint
but neglected to call RemoveAll on the watchpoint list (it does the analogous
work for the internal & external breakpoint lists...)  This patch does the
equivalent cleanup for the watchpoint list.

Added: 


Modified: 
lldb/source/Target/Target.cpp

Removed: 




diff  --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index f16fc6b5da85f..ab6f231772c1f 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -284,6 +284,7 @@ void Target::Destroy() {
   m_breakpoint_list.RemoveAll(notify);
   m_internal_breakpoint_list.RemoveAll(notify);
   m_last_created_breakpoint.reset();
+  m_watchpoint_list.RemoveAll(notify);
   m_last_created_watchpoint.reset();
   m_search_filter_sp.reset();
   m_image_search_paths.Clear(notify);



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D130660: [LLDB] Fix missing return value in SBBreakpointLocation::GetQueueName()

2022-07-27 Thread Jim Ingham via lldb-commits
So far as I can tell, we don't have any significant tests for the "queue 
specific breakpoint or breakpoint location" feature.  There's a pretty 
extensive test for identifying queues & getting more detail from them in 
test/API/macosx/queues/TestQueues.py, but it doesn't test the breakpoint 
feature.

Both SetQueueName and GetQueueName are called in the api/default_constructor 
test, but those tests don't assert anything about values, since they are on 
default-constructed objects.  We also test that we can set a queue name on a 
breakpoint, serialize the breakpoint, deserialize it and get the queue name 
back out.  But we can't reuse that for locations since we don't serialize 
breakpoint locations.

SBBreakpointLocation.{Get,Set}QueueName can be applied to any breakpoint, it 
doesn't require any queue support from the underlying OS.  Get just gets back 
whatever string Set put in.  So for coverage of this bug it should be enough to 
find some test that makes a breakpoint, then set a queue, make sure you get it 
back again.  

But we really should add some tests that show this actually works.

Jim


> On Jul 27, 2022, at 1:15 PM, Greg Clayton via Phabricator via lldb-commits 
>  wrote:
> 
> clayborg added a comment.
> 
> There must be a test for this, obviously we don't have one, but check the 
> blame log and ask the original author how this should be tested.
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D130660/new/
> 
> https://reviews.llvm.org/D130660
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 8b7775a - StackFrame::GetValueObjectForFrameVariable holds the StackFrame lock too long.

2022-07-26 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-07-26T10:13:19-07:00
New Revision: 8b7775a472e3665dc0a9e5953f84c43da295eddd

URL: 
https://github.com/llvm/llvm-project/commit/8b7775a472e3665dc0a9e5953f84c43da295eddd
DIFF: 
https://github.com/llvm/llvm-project/commit/8b7775a472e3665dc0a9e5953f84c43da295eddd.diff

LOG: StackFrame::GetValueObjectForFrameVariable holds the StackFrame lock too 
long.

This can cause a deadlock if other threads use the common pattern of
"lock the StackFrameList, get a frame, lock the StackFrame."

Differential Revision: https://reviews.llvm.org/D130524

Added: 


Modified: 
lldb/source/Target/StackFrame.cpp

Removed: 




diff  --git a/lldb/source/Target/StackFrame.cpp 
b/lldb/source/Target/StackFrame.cpp
index e87cf5af3e399..4fb5ba0b735e6 100644
--- a/lldb/source/Target/StackFrame.cpp
+++ b/lldb/source/Target/StackFrame.cpp
@@ -1145,26 +1145,34 @@ bool StackFrame::HasDebugInformation() {
 ValueObjectSP
 StackFrame::GetValueObjectForFrameVariable(const VariableSP _sp,
DynamicValueType use_dynamic) {
-  std::lock_guard guard(m_mutex);
   ValueObjectSP valobj_sp;
-  if (IsHistorical()) {
-return valobj_sp;
-  }
-  VariableList *var_list = GetVariableList(true);
-  if (var_list) {
-// Make sure the variable is a frame variable
-const uint32_t var_idx = var_list->FindIndexForVariable(variable_sp.get());
-const uint32_t num_variables = var_list->GetSize();
-if (var_idx < num_variables) {
-  valobj_sp = m_variable_list_value_objects.GetValueObjectAtIndex(var_idx);
-  if (!valobj_sp) {
-if (m_variable_list_value_objects.GetSize() < num_variables)
-  m_variable_list_value_objects.Resize(num_variables);
-valobj_sp = ValueObjectVariable::Create(this, variable_sp);
-m_variable_list_value_objects.SetValueObjectAtIndex(var_idx, 
valobj_sp);
+  { // Scope for stack frame mutex.  We need to drop this mutex before we 
figure
+// out the dynamic value.  That will require converting the StackID in the 
+// VO back to a StackFrame, which will in turn require locking the 
+// StackFrameList.  If we still hold the StackFrame mutex, we could suffer 
+// lock inversion against the pattern of getting the StackFrameList and 
+// then the stack frame, which is fairly common.
+std::lock_guard guard(m_mutex);
+if (IsHistorical()) {
+  return valobj_sp;
+}
+VariableList *var_list = GetVariableList(true);
+if (var_list) {
+  // Make sure the variable is a frame variable
+  const uint32_t var_idx = 
var_list->FindIndexForVariable(variable_sp.get());
+  const uint32_t num_variables = var_list->GetSize();
+  if (var_idx < num_variables) {
+valobj_sp = 
m_variable_list_value_objects.GetValueObjectAtIndex(var_idx);
+if (!valobj_sp) {
+  if (m_variable_list_value_objects.GetSize() < num_variables)
+m_variable_list_value_objects.Resize(num_variables);
+  valobj_sp = ValueObjectVariable::Create(this, variable_sp);
+  m_variable_list_value_objects.SetValueObjectAtIndex(var_idx,
+  valobj_sp);
+}
   }
 }
-  }
+  } // End of StackFrame mutex scope.
   if (use_dynamic != eNoDynamicValues && valobj_sp) {
 ValueObjectSP dynamic_sp = valobj_sp->GetDynamicValue(use_dynamic);
 if (dynamic_sp)



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 83fab8c - Revert "Make hit point counts reliable for architectures that stop before evaluation."

2022-07-18 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-07-18T17:38:43-07:00
New Revision: 83fab8cee9d6b9fa911195c20325b4512a7a22ef

URL: 
https://github.com/llvm/llvm-project/commit/83fab8cee9d6b9fa911195c20325b4512a7a22ef
DIFF: 
https://github.com/llvm/llvm-project/commit/83fab8cee9d6b9fa911195c20325b4512a7a22ef.diff

LOG: Revert "Make hit point counts reliable for architectures that stop before 
evaluation."

This reverts commit 5778ada8e54edb2bc2869505b88a959d1915c02f.

The watchpoint tests all stall on aarch64-ubuntu bots.  Reverting till I can
get my hands on an system to test this out.

Added: 


Modified: 
lldb/include/lldb/Breakpoint/Watchpoint.h
lldb/include/lldb/Target/StopInfo.h
lldb/source/Target/StopInfo.cpp

lldb/test/API/commands/watchpoints/watchpoint_commands/condition/TestWatchpointConditionCmd.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentManyWatchpoints.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentNWatchNBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalNWatchNBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatch.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointThreads.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py

Removed: 




diff  --git a/lldb/include/lldb/Breakpoint/Watchpoint.h 
b/lldb/include/lldb/Breakpoint/Watchpoint.h
index 7137b6e4a24c5..41b723a66b6a3 100644
--- a/lldb/include/lldb/Breakpoint/Watchpoint.h
+++ b/lldb/include/lldb/Breakpoint/Watchpoint.h
@@ -157,15 +157,12 @@ class Watchpoint : public 
std::enable_shared_from_this,
 private:
   friend class Target;
   friend class WatchpointList;
-  friend class StopInfoWatchpoint; // This needs to call UndoHitCount()
 
   void ResetHistoricValues() {
 m_old_value_sp.reset();
 m_new_value_sp.reset();
   }
 
-  void UndoHitCount() { m_hit_counter.Decrement(); }
-
   Target _target;
   bool m_enabled;   // Is this watchpoint enabled
   bool m_is_hardware;   // Is this a hardware watchpoint

diff  --git a/lldb/include/lldb/Target/StopInfo.h 
b/lldb/include/lldb/Target/StopInfo.h
index 9527a6ea553e3..cdb906dcd7ede 100644
--- a/lldb/include/lldb/Target/StopInfo.h
+++ b/lldb/include/lldb/Target/StopInfo.h
@@ -17,7 +17,7 @@
 
 namespace lldb_private {
 
-class StopInfo : public std::enable_shared_from_this {
+class StopInfo {
   friend class Process::ProcessEventData;
   friend class ThreadPlanBase;
 

diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index 5cf0f760aa249..00d30070c8c9f 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -20,7 +20,6 @@
 #include "lldb/Target/Target.h"
 #include "lldb/Target/Thread.h"
 #include "lldb/Target/ThreadPlan.h"
-#include "lldb/Target/ThreadPlanStepInstruction.h"
 #include "lldb/Target/UnixSignals.h"
 #include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Log.h"
@@ -691,128 +690,40 @@ class StopInfoWatchpoint : public StopInfo {
   }
 
 protected:
-  using StopInfoWatchpointSP = std::shared_ptr;
-  // This plan is used to orchestrate stepping over the watchpoint for
-  // architectures (e.g. ARM) that report the watch before running the watched
-  // access.  This is the sort of job you have to defer to the thread plans,
-  // if you try to do it directly in the stop info and there are other threads
-  // that needed to process this stop you will have yanked control away from
-  // them and they won't behave correctly.
-  class ThreadPlanStepOverWatchpoint : public ThreadPlanStepInstruction {
-  public:
-ThreadPlanStepOverWatchpoint(Thread , 
- StopInfoWatchpointSP stop_info_sp,
- WatchpointSP watch_sp)
-: ThreadPlanStepInstruction(thread, false, true, eVoteNoOpinion,
-eVoteNoOpinion),
-  m_stop_info_sp(stop_info_sp), m_watch_sp(watch_sp) {
-  assert(watch_sp);
-  m_watch_index = watch_sp->GetHardwareIndex();
-}
-
-bool DoWillResume(lldb::StateType resume_state,
-  bool current_plan) override {
-  if (m_did_reset_watchpoint) {
-GetThread().GetProcess()->DisableWatchpoint(m_watch_sp.get(), false);
-m_did_reset_watchpoint = false;
-  }
- 

[Lldb-commits] [lldb] 4f5707e - Revert "This is a followup to https://reviews.llvm.org/D129814"

2022-07-18 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-07-18T17:37:13-07:00
New Revision: 4f5707e743528a0d40ac154e2e07705a03fd7ad3

URL: 
https://github.com/llvm/llvm-project/commit/4f5707e743528a0d40ac154e2e07705a03fd7ad3
DIFF: 
https://github.com/llvm/llvm-project/commit/4f5707e743528a0d40ac154e2e07705a03fd7ad3.diff

LOG: Revert "This is a followup to https://reviews.llvm.org/D129814;

This reverts commit 555ae5b8f5aa93ab090af853a8b7a83f815b3f20.

Apparently, there's something different about how Linux ARM handles watchpoints,
as all the watchpoint tests seem to stall on the Ubuntu aarch64 bots.

Reverting till I can get my hands on a linux system and see what is
wrong.

Added: 


Modified: 
lldb/source/Target/StopInfo.cpp

Removed: 




diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index 17f6d15059e11..5cf0f760aa249 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -754,22 +754,15 @@ class StopInfoWatchpoint : public StopInfo {
   bool ShouldStopSynchronous(Event *event_ptr) override {
 // If we are running our step-over the watchpoint plan, stop if it's done
 // and continue if it's not:
-if (m_should_stop_is_valid)
-  return m_should_stop;
-
-// If we are running our step over plan, then stop here and let the regular
-// ShouldStop figure out what we should do:  Otherwise, give our plan
-// more time to get run:
 if (m_using_step_over_plan)
   return m_step_over_plan_complete;
 
-Log *log = GetLog(LLDBLog::Process);
 ThreadSP thread_sp(m_thread_wp.lock());
 assert(thread_sp);
 WatchpointSP wp_sp(
 
thread_sp->CalculateTarget()->GetWatchpointList().FindByID(GetValue()));
-// If we can no longer find the watchpoint, we just have to stop:
 if (!wp_sp) {
+  Log *log = GetLog(LLDBLog::Process);
 
   LLDB_LOGF(log,
 "Process::%s could not find watchpoint location id: %" PRId64
@@ -803,42 +796,23 @@ class StopInfoWatchpoint : public StopInfo {
 uint32_t num;
 bool wp_triggers_after;
 
-if (!process_sp->GetWatchpointSupportInfo(num, wp_triggers_after)
+if (process_sp->GetWatchpointSupportInfo(num, wp_triggers_after)
 .Success()) {
-  m_should_stop_is_valid = true;
-  m_should_stop = true;
-  return m_should_stop;
-}
-
-if (!wp_triggers_after) {
-  // We have to step over the breakpoint before we know what to do:   
+  if (wp_triggers_after)
+return true;
+  
   StopInfoWatchpointSP me_as_siwp_sp 
   = std::static_pointer_cast(shared_from_this());
   ThreadPlanSP step_over_wp_sp(new ThreadPlanStepOverWatchpoint(
   *(thread_sp.get()), me_as_siwp_sp, wp_sp));
   Status error;
   error = thread_sp->QueueThreadPlan(step_over_wp_sp, false);
-  // If we couldn't push the thread plan, just stop here:
-  if (!error.Success()) {
-LLDB_LOGF(log, "Could not push our step over watchpoint plan: %s", 
-error.AsCString());
-
-m_should_stop = true;
-m_should_stop_is_valid = true;
-return true;
-  } else {
-  // Otherwise, don't set m_should_stop, we don't know that yet.  Just 
-  // say we should continue:
-m_using_step_over_plan = true;
-return false;
-  }
-} else {
-  // We didn't have to do anything special here, so just return our value:
-  m_should_stop_is_valid = true;
-  return m_should_stop;
+  m_using_step_over_plan = true;
+  return !error.Success();
 }
-
-return m_should_stop;
+// If we don't have to step over the watchpoint, just let the PerformAction
+// determine what we should do.
+return true;
   }
 
   bool ShouldStop(Event *event_ptr) override {



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 555ae5b - This is a followup to https://reviews.llvm.org/D129814

2022-07-18 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-07-18T16:24:31-07:00
New Revision: 555ae5b8f5aa93ab090af853a8b7a83f815b3f20

URL: 
https://github.com/llvm/llvm-project/commit/555ae5b8f5aa93ab090af853a8b7a83f815b3f20
DIFF: 
https://github.com/llvm/llvm-project/commit/555ae5b8f5aa93ab090af853a8b7a83f815b3f20.diff

LOG: This is a followup to https://reviews.llvm.org/D129814

That was causing hit counts to be double-counted on x86_64 Linux.
It looks like StopInfoWatchpoint::ShouldStopSynchronous gets called
twice for a give stop on Linux (not on Darwin).  I had taken out the
"have I been called already" check when I reworked this part of the
code because it didn't seem necessary.  Putting that back in because
it looks like it is on some systems.

Added: 


Modified: 
lldb/source/Target/StopInfo.cpp

Removed: 




diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index 5cf0f760aa249..17f6d15059e11 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -754,15 +754,22 @@ class StopInfoWatchpoint : public StopInfo {
   bool ShouldStopSynchronous(Event *event_ptr) override {
 // If we are running our step-over the watchpoint plan, stop if it's done
 // and continue if it's not:
+if (m_should_stop_is_valid)
+  return m_should_stop;
+
+// If we are running our step over plan, then stop here and let the regular
+// ShouldStop figure out what we should do:  Otherwise, give our plan
+// more time to get run:
 if (m_using_step_over_plan)
   return m_step_over_plan_complete;
 
+Log *log = GetLog(LLDBLog::Process);
 ThreadSP thread_sp(m_thread_wp.lock());
 assert(thread_sp);
 WatchpointSP wp_sp(
 
thread_sp->CalculateTarget()->GetWatchpointList().FindByID(GetValue()));
+// If we can no longer find the watchpoint, we just have to stop:
 if (!wp_sp) {
-  Log *log = GetLog(LLDBLog::Process);
 
   LLDB_LOGF(log,
 "Process::%s could not find watchpoint location id: %" PRId64
@@ -796,23 +803,42 @@ class StopInfoWatchpoint : public StopInfo {
 uint32_t num;
 bool wp_triggers_after;
 
-if (process_sp->GetWatchpointSupportInfo(num, wp_triggers_after)
+if (!process_sp->GetWatchpointSupportInfo(num, wp_triggers_after)
 .Success()) {
-  if (wp_triggers_after)
-return true;
-  
+  m_should_stop_is_valid = true;
+  m_should_stop = true;
+  return m_should_stop;
+}
+
+if (!wp_triggers_after) {
+  // We have to step over the breakpoint before we know what to do:   
   StopInfoWatchpointSP me_as_siwp_sp 
   = std::static_pointer_cast(shared_from_this());
   ThreadPlanSP step_over_wp_sp(new ThreadPlanStepOverWatchpoint(
   *(thread_sp.get()), me_as_siwp_sp, wp_sp));
   Status error;
   error = thread_sp->QueueThreadPlan(step_over_wp_sp, false);
-  m_using_step_over_plan = true;
-  return !error.Success();
+  // If we couldn't push the thread plan, just stop here:
+  if (!error.Success()) {
+LLDB_LOGF(log, "Could not push our step over watchpoint plan: %s", 
+error.AsCString());
+
+m_should_stop = true;
+m_should_stop_is_valid = true;
+return true;
+  } else {
+  // Otherwise, don't set m_should_stop, we don't know that yet.  Just 
+  // say we should continue:
+m_using_step_over_plan = true;
+return false;
+  }
+} else {
+  // We didn't have to do anything special here, so just return our value:
+  m_should_stop_is_valid = true;
+  return m_should_stop;
 }
-// If we don't have to step over the watchpoint, just let the PerformAction
-// determine what we should do.
-return true;
+
+return m_should_stop;
   }
 
   bool ShouldStop(Event *event_ptr) override {



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] e83d47f - When the module path for `command script import` is invalid, echo the path.

2022-07-18 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-07-18T14:49:07-07:00
New Revision: e83d47f6b7bd2f8dcf419e03b3a00d5db5bd61c4

URL: 
https://github.com/llvm/llvm-project/commit/e83d47f6b7bd2f8dcf419e03b3a00d5db5bd61c4
DIFF: 
https://github.com/llvm/llvm-project/commit/e83d47f6b7bd2f8dcf419e03b3a00d5db5bd61c4.diff

LOG: When the module path for `command script import` is invalid, echo the path.

We were just emitting "invalid module" w/o saying which module.  That's
not particularly helpful.

Differential Revision: https://reviews.llvm.org/D129338

Added: 


Modified: 
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/test/API/commands/command/script/import/TestImport.py

Removed: 




diff  --git 
a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp 
b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
index 53e2bcaccafbf..a21adcfbdbd60 100644
--- a/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ b/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -2637,7 +2637,7 @@ bool ScriptInterpreterPythonImpl::LoadScriptingModule(
  .SetSetLLDBGlobals(false);
 
   if (!pathname || !pathname[0]) {
-error.SetErrorString("invalid pathname");
+error.SetErrorString("empty path");
 return false;
   }
 
@@ -2707,14 +2707,14 @@ bool ScriptInterpreterPythonImpl::LoadScriptingModule(
   // if not a valid file of any sort, check if it might be a filename still
   // dot can't be used but / and \ can, and if either is found, reject
   if (strchr(pathname, '\\') || strchr(pathname, '/')) {
-error.SetErrorString("invalid pathname");
+error.SetErrorStringWithFormatv("invalid pathname '{0}'", pathname);
 return false;
   }
   // Not a filename, probably a package of some sort, let it go through.
   possible_package = true;
 } else if (is_directory(st) || is_regular_file(st)) {
   if (module_file.GetDirectory().IsEmpty()) {
-error.SetErrorString("invalid directory name");
+error.SetErrorStringWithFormatv("invalid directory name '{0}'", 
pathname);
 return false;
   }
   if (llvm::Error e =

diff  --git a/lldb/test/API/commands/command/script/import/TestImport.py 
b/lldb/test/API/commands/command/script/import/TestImport.py
index ff1fd145ce395..6f3e61b0b45ea 100644
--- a/lldb/test/API/commands/command/script/import/TestImport.py
+++ b/lldb/test/API/commands/command/script/import/TestImport.py
@@ -38,12 +38,13 @@ def cleanup():
 self.runCmd("command script import ./foo/bar/foobar.py --allow-reload")
 self.runCmd("command script import ./bar/bar.py --allow-reload")
 
+self.expect("command script import ''",
+error=True, startstr="error: module importing failed: 
empty path")
 self.expect("command script import ./nosuchfile.py",
-error=True, startstr='error: module importing failed')
+error=True, startstr="error: module importing failed: 
invalid pathname './nosuchfile.py'")
 self.expect("command script import ./nosuchfolder/",
-error=True, startstr='error: module importing failed')
+error=True, startstr="error: module importing failed: 
invalid pathname './nosuchfolder/'")
 self.expect("command script import ./foo/foo.py", error=False)
-
 self.runCmd("command script import --allow-reload ./thepackage")
 self.expect("TPcommandA", substrs=["hello world A"])
 self.expect("TPcommandB", substrs=["hello world B"])



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 5778ada - Make hit point counts reliable for architectures that stop before evaluation.

2022-07-18 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-07-18T14:36:32-07:00
New Revision: 5778ada8e54edb2bc2869505b88a959d1915c02f

URL: 
https://github.com/llvm/llvm-project/commit/5778ada8e54edb2bc2869505b88a959d1915c02f
DIFF: 
https://github.com/llvm/llvm-project/commit/5778ada8e54edb2bc2869505b88a959d1915c02f.diff

LOG: Make hit point counts reliable for architectures that stop before 
evaluation.

Since we want to present the "new & old" values for watchpoint hits, on 
architectures,
including the ARM family, that stop before the triggering instruction is run, 
we need
to single step over the instruction before stopping for realz.  This was 
incorrectly
done directly in the StopInfoWatchpoint::ShouldStop.  That causes problems if 
more than
one thread stops "for a reason" at the same time as the watchpoint, since the 
other actions
didn't expect the process to make progress in this part of the execution 
control machinery.

The correct way to do this is to schedule the step over using ThreadPlans, and 
then to restore
the stop info after that plan stops, so that the rest of the stop info actions 
can happen when
all the other threads have handled their immediate actions as well.

Differential Revision: https://reviews.llvm.org/D129814

Added: 


Modified: 
lldb/include/lldb/Breakpoint/Watchpoint.h
lldb/include/lldb/Target/StopInfo.h
lldb/source/Target/StopInfo.cpp

lldb/test/API/commands/watchpoints/watchpoint_commands/condition/TestWatchpointConditionCmd.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentManyWatchpoints.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentNWatchNBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalNWatchNBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatch.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointThreads.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py

Removed: 




diff  --git a/lldb/include/lldb/Breakpoint/Watchpoint.h 
b/lldb/include/lldb/Breakpoint/Watchpoint.h
index 41b723a66b6a3..7137b6e4a24c5 100644
--- a/lldb/include/lldb/Breakpoint/Watchpoint.h
+++ b/lldb/include/lldb/Breakpoint/Watchpoint.h
@@ -157,12 +157,15 @@ class Watchpoint : public 
std::enable_shared_from_this,
 private:
   friend class Target;
   friend class WatchpointList;
+  friend class StopInfoWatchpoint; // This needs to call UndoHitCount()
 
   void ResetHistoricValues() {
 m_old_value_sp.reset();
 m_new_value_sp.reset();
   }
 
+  void UndoHitCount() { m_hit_counter.Decrement(); }
+
   Target _target;
   bool m_enabled;   // Is this watchpoint enabled
   bool m_is_hardware;   // Is this a hardware watchpoint

diff  --git a/lldb/include/lldb/Target/StopInfo.h 
b/lldb/include/lldb/Target/StopInfo.h
index cdb906dcd7ede..9527a6ea553e3 100644
--- a/lldb/include/lldb/Target/StopInfo.h
+++ b/lldb/include/lldb/Target/StopInfo.h
@@ -17,7 +17,7 @@
 
 namespace lldb_private {
 
-class StopInfo {
+class StopInfo : public std::enable_shared_from_this {
   friend class Process::ProcessEventData;
   friend class ThreadPlanBase;
 

diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index 00d30070c8c9f..5cf0f760aa249 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -20,6 +20,7 @@
 #include "lldb/Target/Target.h"
 #include "lldb/Target/Thread.h"
 #include "lldb/Target/ThreadPlan.h"
+#include "lldb/Target/ThreadPlanStepInstruction.h"
 #include "lldb/Target/UnixSignals.h"
 #include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Log.h"
@@ -690,40 +691,128 @@ class StopInfoWatchpoint : public StopInfo {
   }
 
 protected:
+  using StopInfoWatchpointSP = std::shared_ptr;
+  // This plan is used to orchestrate stepping over the watchpoint for
+  // architectures (e.g. ARM) that report the watch before running the watched
+  // access.  This is the sort of job you have to defer to the thread plans,
+  // if you try to do it directly in the stop info and there are other threads
+  // that needed to process this stop you will have yanked control away from
+  // them and they won't behave correctly.
+  class ThreadPlanStepOverWatchpoint : public ThreadPlanStepInstruction {
+  public:
+ThreadPlanStepOverWatchpoint(Thread , 
+ 

[Lldb-commits] [lldb] 38ca754 - Apparently you need a special makefile flag to use threads on Linux.

2022-06-30 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2022-06-30T12:10:17-07:00
New Revision: 38ca754eb08b0741511c74bbac123e551f54125b

URL: 
https://github.com/llvm/llvm-project/commit/38ca754eb08b0741511c74bbac123e551f54125b
DIFF: 
https://github.com/llvm/llvm-project/commit/38ca754eb08b0741511c74bbac123e551f54125b.diff

LOG: Apparently you need a special makefile flag to use threads on Linux.

This is a follow-up to https://reviews.llvm.org/D128776.

Added: 


Modified: 
lldb/test/API/functionalities/breakpoint/two_hits_one_actual/Makefile

Removed: 




diff  --git 
a/lldb/test/API/functionalities/breakpoint/two_hits_one_actual/Makefile 
b/lldb/test/API/functionalities/breakpoint/two_hits_one_actual/Makefile
index 8b20bcb05..c46619c662348 100644
--- a/lldb/test/API/functionalities/breakpoint/two_hits_one_actual/Makefile
+++ b/lldb/test/API/functionalities/breakpoint/two_hits_one_actual/Makefile
@@ -1,3 +1,4 @@
 CXX_SOURCES := main.cpp
+ENABLE_THREADS := YES
 
 include Makefile.rules



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


  1   2   3   4   5   6   7   8   9   10   >