date:20210526

[Lldb-commits] [PATCH] D103210: [lldb] Introduce Language::MethodNameInfo

2021-05-26 Thread Jim Ingham via Phabricator via lldb-commits

jingham added a comment.

The idea seems good, but I'm not sure how you are going to extend it?  
"Selector" seems a pretty ObjC specific term to me.  Will this be what you use 
to get the "method name" part of the C++ names?  That would look a bit odd to 
me, but OTOH having a GetSelector in all the subclasses, most of which don't 
have selectors also seems a little odd.  This might be solved by just thinking 
of a better name, however.  Also note, in the C++ case, it would be useful to 
distinguish between the method name, like Bar in Foo::Bar, and the fully 
qualified method name (like Bar(int, double) in Foo::Bar(int, double).  That 
might effect the choice of names.  The selector is the equivalent of a C++ 
fully qualified method name.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103210/new/

https://reviews.llvm.org/D103210

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

[Lldb-commits] [PATCH] D103217: Make ignore counts work as "after stop" modifiers so they play nicely with conditions

2021-05-26 Thread Jim Ingham via Phabricator via lldb-commits

jingham created this revision.
jingham added a reviewer: JDevlieghere.
jingham requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Previously ignore counts were checked when we stopped to do the sync callback 
in Breakpoint::ShouldStop.  That meant we would do all the ignore count work 
even when there is also a condition says the breakpoint should not stop.

That's wrong, lldb treats breakpoint hits that fail the thread or condition 
checks as "not having hit the breakpoint".  So the ignore count check should 
happen after the condition and thread checks in 
StopInfoBreakpoint::PerformAction.

The one side-effect of doing this is that if you have a breakpoint with a 
synchronous callback, it will run the synchronous callback before checking the 
ignore count.  That is probably a good thing, since this was already true of 
the condition and thread checks, so this removes an odd asymmetry.  And 
breakpoints with sync callbacks are all internal lldb breakpoints and there's 
not a really good reason why you would want one of these to use an ignore count 
(but not a condition or thread check...)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103217

Files:
  lldb/include/lldb/Breakpoint/Breakpoint.h
  lldb/include/lldb/Breakpoint/BreakpointLocation.h
  lldb/source/Breakpoint/Breakpoint.cpp
  lldb/source/Breakpoint/BreakpointLocation.cpp
  lldb/source/Target/StopInfo.cpp
  
lldb/test/API/functionalities/breakpoint/breakpoint_ignore_count/TestBreakpointIgnoreCount.py
  lldb/test/API/functionalities/breakpoint/breakpoint_ignore_count/main.c

Index: lldb/test/API/functionalities/breakpoint/breakpoint_ignore_count/main.c
===
--- lldb/test/API/functionalities/breakpoint/breakpoint_ignore_count/main.c
+++ lldb/test/API/functionalities/breakpoint/breakpoint_ignore_count/main.c
@@ -29,9 +29,15 @@
 return val + 3; // Find the line number of function "c" here.
 }
 
+void spin_a_bit () {
+  for (unsigned int i = 0; i < 10; i++) {
+printf("Set a breakpoint here, with i = %d.\n", i);
+  }
+}
+
 int main (int argc, char const *argv[])
 {
-int A1 = a(1);  // a(1) -> b(1) -> c(1)
+int A1 = a(1);  // a(1) -> b(1) -> c(1) // Stop here at start of main
 printf("a(1) returns %d\n", A1);
 
 int B2 = b(2);  // b(2) -> c(2) Find the call site of b(2).
@@ -42,5 +48,7 @@
 
 int C1 = c(5); // Find the call site of c in main.
 printf ("c(5) returns %d\n", C1);
+
+spin_a_bit();
 return 0;
 }
Index: lldb/test/API/functionalities/breakpoint/breakpoint_ignore_count/TestBreakpointIgnoreCount.py
===
--- lldb/test/API/functionalities/breakpoint/breakpoint_ignore_count/TestBreakpointIgnoreCount.py
+++ lldb/test/API/functionalities/breakpoint/breakpoint_ignore_count/TestBreakpointIgnoreCount.py
@@ -27,10 +27,21 @@
 self.build()
 self.breakpoint_ignore_count_python()
 
+@skipIfWindows # This test will hang on windows llvm.org/pr21753
+def test_ignore_vrs_condition_bkpt(self):
+self.build()
+self.ignore_vrs_condition(False)
+
+@skipIfWindows # This test will hang on windows llvm.org/pr21753
+def test_ignore_vrs_condition_loc(self):
+self.build()
+self.ignore_vrs_condition(True)
+
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
 # Find the line number to of function 'c'.
+self.stop_in_main = "Stop here at start of main"
 self.line1 = line_number(
 'main.c', '// Find the line number of function "c" here.')
 self.line2 = line_number(
@@ -99,8 +110,9 @@
 
 def breakpoint_ignore_count_python(self):
 """Use Python APIs to set breakpoint ignore count."""
-target = self.createTestTarget()
-
+target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(self,
+  self.stop_in_main,
+  lldb.SBFileSpec("main.c"))
 # Now create a breakpoint on main.c by name 'c'.
 breakpoint = target.BreakpointCreateByName('c', 'a.out')
 self.assertTrue(breakpoint and
@@ -119,10 +131,8 @@
 self.assertEqual(location.GetIgnoreCount(), 2,
 "SetIgnoreCount() works correctly")
 
-# 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)
+# Now continue and hit our breakpoint on c:
+process.Continue()
 
 # Frame#0 should be on main.c:37, frame#1 should be on main.c:25, and
 # frame#2 should be on main.c:48.
@@ -143,4 +153,31 @@
 # The hit count for the

[Lldb-commits] [PATCH] D103210: [lldb] Introduce Language::MethodNameInfo

2021-05-26 Thread Alex Langford via Phabricator via lldb-commits

bulbazord added a comment.

Let me know how you feel about this abstraction/idea. I think we'll need 
something like this at some point to remove most of the remaining dependencies 
(e.g. in Module.cpp) so I'd like to get something good going here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103210/new/

https://reviews.llvm.org/D103210

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

[Lldb-commits] [PATCH] D103210: [lldb] Introduce Language::MethodNameInfo

2021-05-26 Thread Alex Langford via Phabricator via lldb-commits

bulbazord created this revision.
bulbazord added a reviewer: teemperor.
bulbazord requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

There are several instances where one may want to ask questions about
the name of a method/function/whatever. Classes like
CPlusPlusLanguage::MethodName and ObjCLanguage::MethodName fulfill this
purpose right now, but users of these have to have knowledge on these
classes (from plugins) to function. I propose a new class
`Language::MethodNameInfo` to abstract this away so that lldb's Core
libraries can ask questions about a method name without knowing the
details of a plugin.

Currently the class only has one method to override, `GetSelector`, but
I imagine it will have more in the future. I only added the one method
needed to replace the use of `ObjCLanguage` in Symtab.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103210

Files:
  lldb/include/lldb/Target/Language.h
  lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
  lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
  lldb/source/Symbol/Symtab.cpp
  lldb/source/Target/Language.cpp

Index: lldb/source/Target/Language.cpp
===
--- lldb/source/Target/Language.cpp
+++ lldb/source/Target/Language.cpp
@@ -356,6 +356,11 @@
   return PluginManager::GetREPLAllTypeSystemSupportedLanguages();
 }
 
+std::unique_ptr
+Language::GetMethodNameInfo(llvm::StringRef name) {
+  return nullptr;
+}
+
 std::unique_ptr Language::GetTypeScavenger() {
   return nullptr;
 }
Index: lldb/source/Symbol/Symtab.cpp
===
--- lldb/source/Symbol/Symtab.cpp
+++ lldb/source/Symbol/Symtab.cpp
@@ -9,8 +9,6 @@
 #include 
 #include 
 
-#include "Plugins/Language/ObjC/ObjCLanguage.h"
-
 #include "lldb/Core/Module.h"
 #include "lldb/Core/RichManglingContext.h"
 #include "lldb/Core/Section.h"
@@ -18,6 +16,7 @@
 #include "lldb/Symbol/Symbol.h"
 #include "lldb/Symbol/SymbolContext.h"
 #include "lldb/Symbol/Symtab.h"
+#include "lldb/Target/Language.h"
 #include "lldb/Utility/RegularExpression.h"
 #include "lldb/Utility/Stream.h"
 #include "lldb/Utility/Timer.h"
@@ -311,13 +310,16 @@
 
 // If the demangled name turns out to be an ObjC name, and is a category
 // name, add the version without categories to the index too.
-ObjCLanguage::MethodName objc_method(name.GetStringRef(), true);
-if (objc_method.IsValid(true)) {
-  m_selector_to_index.Append(objc_method.GetSelector(), value);
-
-  if (ConstString objc_method_no_category =
-  objc_method.GetFullNameWithoutCategory(true))
-m_name_to_index.Append(objc_method_no_category, value);
+if (auto *objc_lang = Language::FindPlugin(lldb::eLanguageTypeObjC)) {
+  if (std::unique_ptr method_name_info =
+  objc_lang->GetMethodNameInfo(name.GetStringRef())) {
+m_selector_to_index.Append(
+method_name_info->GetSelector().getValue(), value);
+for (ConstString objc_method_variant :
+ objc_lang->GetMethodNameVariants(name)) {
+  m_name_to_index.Append(objc_method_variant, value);
+}
+  }
 }
   }
 }
Index: lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
===
--- lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
+++ lldb/source/Plugins/Language/ObjC/ObjCLanguage.h
@@ -85,6 +85,18 @@
 bool m_category_is_valid;
   };
 
+  class ObjCMethodNameInfo : public Language::MethodNameInfo {
+ObjCLanguage::MethodName m_method_name;
+
+  public:
+ObjCMethodNameInfo(llvm::StringRef name) : m_method_name(name, true) {}
+
+bool IsValid() { return m_method_name.IsValid(true); }
+llvm::Optional GetSelector() override {
+  return m_method_name.GetSelector();
+}
+  };
+
   ObjCLanguage() = default;
 
   ~ObjCLanguage() override = default;
@@ -111,6 +123,9 @@
   GetPossibleFormattersMatches(ValueObject &valobj,
lldb::DynamicValueType use_dynamic) override;
 
+  std::unique_ptr
+  GetMethodNameInfo(llvm::StringRef name) override;
+
   std::unique_ptr GetTypeScavenger() override;
 
   bool GetFormatterPrefixSuffix(ValueObject &valobj, ConstString type_hint,
Index: lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
===
--- lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
+++ lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
@@ -935,6 +935,16 @@
   return result;
 }
 
+std::unique_ptr
+ObjCLanguage::GetMethodNameInfo(llvm::StringRef name) {
+  if (auto ret = std::make_unique(name)) {
+if (ret->IsValid()) {
+  return ret;
+}
+  }
+  return nullptr;
+}
+
 std::unique_ptr ObjCLanguage::GetTypeScavenger() {
   class ObjCScavengerResult : public Language::Type

[Lldb-commits] [PATCH] D103209: [lldb] Fix gnu_libstdcpp's update methods

2021-05-26 Thread walter erquinigo via Phabricator via lldb-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0283abee5c87: [lldb] Fix gnu_libstdcpp's update methods 
(authored by wallace).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103209/new/

https://reviews.llvm.org/D103209

Files:
  lldb/examples/synthetic/gnu_libstdcpp.py
  lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
  lldb/test/API/tools/lldb-vscode/evaluate/main.cpp

Index: lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
===
--- lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -1,5 +1,8 @@
 #include "foo.h"
 
+#include 
+#include 
+
 static int static_int = 42;
 
 int non_static_int = 43;
@@ -25,5 +28,21 @@
   }
   a_function(var3);
   foo_func();
+
+  std::vector my_vec;
+  my_vec.push_back(1);
+  my_vec.push_back(2);
+  my_vec.push_back(3); // breakpoint 4
+
+  std::map my_map;
+  my_map[1] = 2;
+  my_map[2] = 3;
+  my_map[3] = 4; // breakpoint 5
+
+  std::vector my_bool_vec;
+  my_bool_vec.push_back(true);
+  my_bool_vec.push_back(false); // breakpoint 6
+  my_bool_vec.push_back(true); // breakpoint 7
+  
   return 0;
 }
Index: lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
===
--- lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
+++ lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
@@ -39,7 +39,11 @@
 [
 line_number(source, "// breakpoint 1"),
 line_number(source, "// breakpoint 2"),
-line_number(source, "// breakpoint 3")
+line_number(source, "// breakpoint 3"),
+line_number(source, "// breakpoint 4"),
+line_number(source, "// breakpoint 5"),
+line_number(source, "// breakpoint 6"),
+line_number(source, "// breakpoint 7"),
 ]
 )
 self.continue_to_next_stop()
@@ -132,6 +136,20 @@
 self.assertEvaluateFailure("foo_func")
 self.assertEvaluateFailure("foo_var")
 
+# Now we check that values are updated after stepping
+self.continue_to_next_stop()
+self.assertEvaluate("my_vec", "size=2")
+self.continue_to_next_stop()
+self.assertEvaluate("my_vec", "size=3")
+
+self.assertEvaluate("my_map", "size=2")
+self.continue_to_next_stop()
+self.assertEvaluate("my_map", "size=3")
+
+self.assertEvaluate("my_bool_vec", "size=1")
+self.continue_to_next_stop()
+self.assertEvaluate("my_bool_vec", "size=2")
+
 @skipIfWindows
 @skipIfRemote
 def test_generic_evaluate_expressions(self):
Index: lldb/examples/synthetic/gnu_libstdcpp.py
===
--- lldb/examples/synthetic/gnu_libstdcpp.py
+++ lldb/examples/synthetic/gnu_libstdcpp.py
@@ -148,6 +148,7 @@
 self.data_size = self.data_type.GetByteSize()
 except:
 pass
+return False
 
 def has_children(self):
 return True
@@ -235,7 +236,7 @@
 self.count = 0
 except:
 pass
-return True
+return False 
 
 class StdVBoolImplementation(object):
 
@@ -282,7 +283,7 @@
 self.valid = True
 except:
 self.valid = False
-return True
+return False
 
 def __init__(self, valobj, dict):
 logger = lldb.formatters.Logger.Logger()
@@ -378,6 +379,7 @@
 self.skip_size = self.Mheader.GetType().GetByteSize()
 except:
 pass
+return False
 
 def num_children(self):
 logger = lldb.formatters.Logger.Logger()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 0283abe - [lldb] Fix gnu_libstdcpp's update methods

2021-05-26 Thread Walter Erquinigo via lldb-commits


Author: Walter Erquinigo
Date: 2021-05-26T14:52:38-07:00
New Revision: 0283abee5c87e86552b456a34d01311b66c37207

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

LOG: [lldb] Fix gnu_libstdcpp's update methods

The variable.rst documentation says:

```
If it returns a value, and that value is True, LLDB will be allowed to cache 
the children and the children count it previously obtained, and will not return 
to the provider class to ask.  If nothing, None, or anything other than True is 
returned, LLDB will discard the cached information and ask. Regardless, 
whenever necessary LLDB will call update.
```

However, several update methods in gnu_libstdcpp.py were returning True,
which made lldb unaware of any changes in the corresponding objects.
This problem was visible by lldb-vscode in the following way:

- If a breakpoint is hit and there's a vector with the contents {1, 2},
  it'll be displayed correctly.
- Then the user steps and the next stop contains the vector modified.
  The program changed it to {1, 2, 3}
- frame var then displays {1, 2} incorrectly, due to the caching caused
by the update method

It's worth mentioning that none of libcxx.py'd update methods return True. Same 
for LibCxxVector.cpp, which returns false.

Added a very simple test that fails without this fix.

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

Added: 


Modified: 
lldb/examples/synthetic/gnu_libstdcpp.py
lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
lldb/test/API/tools/lldb-vscode/evaluate/main.cpp

Removed: 




diff  --git a/lldb/examples/synthetic/gnu_libstdcpp.py 
b/lldb/examples/synthetic/gnu_libstdcpp.py
index 35f009e1bcba8..528b28349bb1a 100644
--- a/lldb/examples/synthetic/gnu_libstdcpp.py
+++ b/lldb/examples/synthetic/gnu_libstdcpp.py
@@ -148,6 +148,7 @@ def update(self):
 self.data_size = self.data_type.GetByteSize()
 except:
 pass
+return False
 
 def has_children(self):
 return True
@@ -235,7 +236,7 @@ def update(self):
 self.count = 0
 except:
 pass
-return True
+return False 
 
 class StdVBoolImplementation(object):
 
@@ -282,7 +283,7 @@ def update(self):
 self.valid = True
 except:
 self.valid = False
-return True
+return False
 
 def __init__(self, valobj, dict):
 logger = lldb.formatters.Logger.Logger()
@@ -378,6 +379,7 @@ def update(self):
 self.skip_size = self.Mheader.GetType().GetByteSize()
 except:
 pass
+return False
 
 def num_children(self):
 logger = lldb.formatters.Logger.Logger()

diff  --git a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py 
b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
index c0ccd2ef43be3..fdd5c47398d00 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
@@ -39,7 +39,11 @@ def run_test_evaluate_expressions(self, context=None):
 [
 line_number(source, "// breakpoint 1"),
 line_number(source, "// breakpoint 2"),
-line_number(source, "// breakpoint 3")
+line_number(source, "// breakpoint 3"),
+line_number(source, "// breakpoint 4"),
+line_number(source, "// breakpoint 5"),
+line_number(source, "// breakpoint 6"),
+line_number(source, "// breakpoint 7"),
 ]
 )
 self.continue_to_next_stop()
@@ -132,6 +136,20 @@ def run_test_evaluate_expressions(self, context=None):
 self.assertEvaluateFailure("foo_func")
 self.assertEvaluateFailure("foo_var")
 
+# Now we check that values are updated after stepping
+self.continue_to_next_stop()
+self.assertEvaluate("my_vec", "size=2")
+self.continue_to_next_stop()
+self.assertEvaluate("my_vec", "size=3")
+
+self.assertEvaluate("my_map", "size=2")
+self.continue_to_next_stop()
+self.assertEvaluate("my_map", "size=3")
+
+self.assertEvaluate("my_bool_vec", "size=1")
+self.continue_to_next_stop()
+self.assertEvaluate("my_bool_vec", "size=2")
+
 @skipIfWindows
 @skipIfRemote
 def test_generic_evaluate_expressions(self):

diff  --git a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp 
b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
index 564660da7119c..3a541b21b2208 100644
--- a/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ b/lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -1,5 +1,8 @@
 #includ

[Lldb-commits] [PATCH] D103209: [lldb] Fix gnu_libstdcpp's update methods

2021-05-26 Thread walter erquinigo via Phabricator via lldb-commits

wallace created this revision.
wallace requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

The variable.rst documentation says:

  If it returns a value, and that value is True, LLDB will be allowed to cache 
the children and the children count it previously obtained, and will not return 
to the provider class to ask.  If nothing, None, or anything other than True is 
returned, LLDB will discard the cached information and ask. Regardless, 
whenever necessary LLDB will call update.

However, several update methods in gnu_libstdcpp.py were returning True,
which made lldb unaware of any changes in the corresponding objects.
This problem was visible by lldb-vscode in the following way:

- If a breakpoint is hit and there's a vector with the contents {1, 2}, it'll 
be displayed correctly.
- Then the user steps and the next stop contains the vector modified. The 
program changed it to {1, 2, 3}
- frame var then displays {1, 2} incorrectly, due to the caching caused

by the update method

It's worth mentioning that none of libcxx.py'd update methods return True. Same 
for LibCxxVector.cpp, which returns false.

Added a very simple test that fails without this fix.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103209

Files:
  lldb/examples/synthetic/gnu_libstdcpp.py
  lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
  lldb/test/API/tools/lldb-vscode/evaluate/main.cpp

Index: lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
===
--- lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
+++ lldb/test/API/tools/lldb-vscode/evaluate/main.cpp
@@ -1,5 +1,8 @@
 #include "foo.h"
 
+#include 
+#include 
+
 static int static_int = 42;
 
 int non_static_int = 43;
@@ -25,5 +28,21 @@
   }
   a_function(var3);
   foo_func();
+
+  std::vector my_vec;
+  my_vec.push_back(1);
+  my_vec.push_back(2);
+  my_vec.push_back(3); // breakpoint 4
+
+  std::map my_map;
+  my_map[1] = 2;
+  my_map[2] = 3;
+  my_map[3] = 4; // breakpoint 5
+
+  std::vector my_bool_vec;
+  my_bool_vec.push_back(true);
+  my_bool_vec.push_back(false); // breakpoint 6
+  my_bool_vec.push_back(true); // breakpoint 7
+  
   return 0;
 }
Index: lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
===
--- lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
+++ lldb/test/API/tools/lldb-vscode/evaluate/TestVSCode_evaluate.py
@@ -39,7 +39,11 @@
 [
 line_number(source, "// breakpoint 1"),
 line_number(source, "// breakpoint 2"),
-line_number(source, "// breakpoint 3")
+line_number(source, "// breakpoint 3"),
+line_number(source, "// breakpoint 4"),
+line_number(source, "// breakpoint 5"),
+line_number(source, "// breakpoint 6"),
+line_number(source, "// breakpoint 7"),
 ]
 )
 self.continue_to_next_stop()
@@ -132,6 +136,20 @@
 self.assertEvaluateFailure("foo_func")
 self.assertEvaluateFailure("foo_var")
 
+# Now we check that values are updated after stepping
+self.continue_to_next_stop()
+self.assertEvaluate("my_vec", "size=2")
+self.continue_to_next_stop()
+self.assertEvaluate("my_vec", "size=3")
+
+self.assertEvaluate("my_map", "size=2")
+self.continue_to_next_stop()
+self.assertEvaluate("my_map", "size=3")
+
+self.assertEvaluate("my_bool_vec", "size=1")
+self.continue_to_next_stop()
+self.assertEvaluate("my_bool_vec", "size=2")
+
 @skipIfWindows
 @skipIfRemote
 def test_generic_evaluate_expressions(self):
Index: lldb/examples/synthetic/gnu_libstdcpp.py
===
--- lldb/examples/synthetic/gnu_libstdcpp.py
+++ lldb/examples/synthetic/gnu_libstdcpp.py
@@ -148,6 +148,7 @@
 self.data_size = self.data_type.GetByteSize()
 except:
 pass
+return False
 
 def has_children(self):
 return True
@@ -235,7 +236,7 @@
 self.count = 0
 except:
 pass
-return True
+return False 
 
 class StdVBoolImplementation(object):
 
@@ -282,7 +283,7 @@
 self.valid = True
 except:
 self.valid = False
-return True
+return False
 
 def __init__(self, valobj, dict):
 logger = lldb.formatters.Logger.Logger()
@@ -378,6 +379,7 @@
 self.skip_size = self.Mheader.GetType().GetByteSize()
 except:
 pass
+return False
 
 def num_children(self):
 logger = lldb.formatters.Logger.Logger()
___
lldb-commits mailing list
lldb-comm

[Lldb-commits] [PATCH] D103172: [lldb][NFC] Allow range-based for loops over DWARFDIE's children

2021-05-26 Thread Shafik Yaghmour via Phabricator via lldb-commits

shafik added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h:117
+// (CU, (DIE)nullptr) == (nullptr, nullptr) -> true
+if (!m_die.IsValid() && !it.m_die.IsValid())
+  return true;

I think:

```
bool operator==(const DWARFBaseDIE &lhs, const DWARFBaseDIE &rhs) {
  return lhs.GetDIE() == rhs.GetDIE() && lhs.GetCU() == rhs.GetCU();
}
```

will do the same thing but maybe I am confused.

Maybe we should have a unit test?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103172/new/

https://reviews.llvm.org/D103172

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

[Lldb-commits] [PATCH] D103124: [lldb] add LLDB_SKIP_DSYM option

2021-05-26 Thread Shoaib Meenai via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG969eefd98e0f: [lldb] add LLDB_SKIP_DSYM option (authored by 
rmaz, committed by smeenai).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103124/new/

https://reviews.llvm.org/D103124

Files:
  lldb/cmake/modules/AddLLDB.cmake
  lldb/cmake/modules/LLDBConfig.cmake


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -65,6 +65,7 @@
 option(LLDB_NO_INSTALL_DEFAULT_RPATH "Disable default RPATH settings in 
binaries" OFF)
 option(LLDB_USE_SYSTEM_DEBUGSERVER "Use the system's debugserver for testing 
(Darwin only)." OFF)
 option(LLDB_SKIP_STRIP "Whether to skip stripping of binaries when installing 
lldb." OFF)
+option(LLDB_SKIP_DSYM "Whether to skip generating a dSYM when installing 
lldb." OFF)
 
 if (LLDB_USE_SYSTEM_DEBUGSERVER)
   # The custom target for the system debugserver has no install target, so we
Index: lldb/cmake/modules/AddLLDB.cmake
===
--- lldb/cmake/modules/AddLLDB.cmake
+++ lldb/cmake/modules/AddLLDB.cmake
@@ -276,19 +276,21 @@
   endif()
 
   # Generate dSYM
-  set(dsym_name ${output_name}.dSYM)
-  if(is_framework)
-set(dsym_name ${output_name}.framework.dSYM)
-  endif()
-  if(LLDB_DEBUGINFO_INSTALL_PREFIX)
-# This makes the path absolute, so we must respect DESTDIR.
-set(dsym_name 
"\$ENV\{DESTDIR\}${LLDB_DEBUGINFO_INSTALL_PREFIX}/${dsym_name}")
-  endif()
+  if(NOT LLDB_SKIP_DSYM)
+set(dsym_name ${output_name}.dSYM)
+if(is_framework)
+  set(dsym_name ${output_name}.framework.dSYM)
+endif()
+if(LLDB_DEBUGINFO_INSTALL_PREFIX)
+  # This makes the path absolute, so we must respect DESTDIR.
+  set(dsym_name 
"\$ENV\{DESTDIR\}${LLDB_DEBUGINFO_INSTALL_PREFIX}/${dsym_name}")
+endif()
 
-  set(buildtree_name ${buildtree_dir}/${bundle_subdir}${output_name})
-  install(CODE "message(STATUS \"Externalize debuginfo: ${dsym_name}\")" 
COMPONENT ${name})
-  install(CODE "execute_process(COMMAND xcrun dsymutil -o=${dsym_name} 
${buildtree_name})"
-  COMPONENT ${name})
+set(buildtree_name ${buildtree_dir}/${bundle_subdir}${output_name})
+install(CODE "message(STATUS \"Externalize debuginfo: ${dsym_name}\")" 
COMPONENT ${name})
+install(CODE "execute_process(COMMAND xcrun dsymutil -o=${dsym_name} 
${buildtree_name})"
+COMPONENT ${name})
+  endif()
 
   if(NOT LLDB_SKIP_STRIP)
 # Strip distribution binary with -ST (removing debug symbol table entries 
and


Index: lldb/cmake/modules/LLDBConfig.cmake
===
--- lldb/cmake/modules/LLDBConfig.cmake
+++ lldb/cmake/modules/LLDBConfig.cmake
@@ -65,6 +65,7 @@
 option(LLDB_NO_INSTALL_DEFAULT_RPATH "Disable default RPATH settings in binaries" OFF)
 option(LLDB_USE_SYSTEM_DEBUGSERVER "Use the system's debugserver for testing (Darwin only)." OFF)
 option(LLDB_SKIP_STRIP "Whether to skip stripping of binaries when installing lldb." OFF)
+option(LLDB_SKIP_DSYM "Whether to skip generating a dSYM when installing lldb." OFF)
 
 if (LLDB_USE_SYSTEM_DEBUGSERVER)
   # The custom target for the system debugserver has no install target, so we
Index: lldb/cmake/modules/AddLLDB.cmake
===
--- lldb/cmake/modules/AddLLDB.cmake
+++ lldb/cmake/modules/AddLLDB.cmake
@@ -276,19 +276,21 @@
   endif()
 
   # Generate dSYM
-  set(dsym_name ${output_name}.dSYM)
-  if(is_framework)
-set(dsym_name ${output_name}.framework.dSYM)
-  endif()
-  if(LLDB_DEBUGINFO_INSTALL_PREFIX)
-# This makes the path absolute, so we must respect DESTDIR.
-set(dsym_name "\$ENV\{DESTDIR\}${LLDB_DEBUGINFO_INSTALL_PREFIX}/${dsym_name}")
-  endif()
+  if(NOT LLDB_SKIP_DSYM)
+set(dsym_name ${output_name}.dSYM)
+if(is_framework)
+  set(dsym_name ${output_name}.framework.dSYM)
+endif()
+if(LLDB_DEBUGINFO_INSTALL_PREFIX)
+  # This makes the path absolute, so we must respect DESTDIR.
+  set(dsym_name "\$ENV\{DESTDIR\}${LLDB_DEBUGINFO_INSTALL_PREFIX}/${dsym_name}")
+endif()
 
-  set(buildtree_name ${buildtree_dir}/${bundle_subdir}${output_name})
-  install(CODE "message(STATUS \"Externalize debuginfo: ${dsym_name}\")" COMPONENT ${name})
-  install(CODE "execute_process(COMMAND xcrun dsymutil -o=${dsym_name} ${buildtree_name})"
-  COMPONENT ${name})
+set(buildtree_name ${buildtree_dir}/${bundle_subdir}${output_name})
+install(CODE "message(STATUS \"Externalize debuginfo: ${dsym_name}\")" COMPONENT ${name})
+install(CODE "execute_process(COMMAND xcrun dsymutil -o=${dsym_name} ${buildtree_name})"
+COMPONENT ${name})
+  endif()
 
   if(NOT LLDB_SKIP_STRIP)
 # Strip distribution binary with -ST (removing debug

[Lldb-commits] [lldb] 969eefd - [lldb] add LLDB_SKIP_DSYM option

2021-05-26 Thread Shoaib Meenai via lldb-commits


Author: Richard Howell
Date: 2021-05-26T09:32:59-07:00
New Revision: 969eefd98e0f8e485148be61190cc2ef62fb1eca

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

LOG: [lldb] add LLDB_SKIP_DSYM option

Add an option to skip generating a dSYM when installing the LLDB framework on 
Darwin.

Reviewed By: smeenai

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

Added: 


Modified: 
lldb/cmake/modules/AddLLDB.cmake
lldb/cmake/modules/LLDBConfig.cmake

Removed: 




diff  --git a/lldb/cmake/modules/AddLLDB.cmake 
b/lldb/cmake/modules/AddLLDB.cmake
index 4ed5c647c5d2a..8be214a8509a5 100644
--- a/lldb/cmake/modules/AddLLDB.cmake
+++ b/lldb/cmake/modules/AddLLDB.cmake
@@ -276,19 +276,21 @@ function(lldb_add_post_install_steps_darwin name 
install_prefix)
   endif()
 
   # Generate dSYM
-  set(dsym_name ${output_name}.dSYM)
-  if(is_framework)
-set(dsym_name ${output_name}.framework.dSYM)
-  endif()
-  if(LLDB_DEBUGINFO_INSTALL_PREFIX)
-# This makes the path absolute, so we must respect DESTDIR.
-set(dsym_name 
"\$ENV\{DESTDIR\}${LLDB_DEBUGINFO_INSTALL_PREFIX}/${dsym_name}")
-  endif()
+  if(NOT LLDB_SKIP_DSYM)
+set(dsym_name ${output_name}.dSYM)
+if(is_framework)
+  set(dsym_name ${output_name}.framework.dSYM)
+endif()
+if(LLDB_DEBUGINFO_INSTALL_PREFIX)
+  # This makes the path absolute, so we must respect DESTDIR.
+  set(dsym_name 
"\$ENV\{DESTDIR\}${LLDB_DEBUGINFO_INSTALL_PREFIX}/${dsym_name}")
+endif()
 
-  set(buildtree_name ${buildtree_dir}/${bundle_subdir}${output_name})
-  install(CODE "message(STATUS \"Externalize debuginfo: ${dsym_name}\")" 
COMPONENT ${name})
-  install(CODE "execute_process(COMMAND xcrun dsymutil -o=${dsym_name} 
${buildtree_name})"
-  COMPONENT ${name})
+set(buildtree_name ${buildtree_dir}/${bundle_subdir}${output_name})
+install(CODE "message(STATUS \"Externalize debuginfo: ${dsym_name}\")" 
COMPONENT ${name})
+install(CODE "execute_process(COMMAND xcrun dsymutil -o=${dsym_name} 
${buildtree_name})"
+COMPONENT ${name})
+  endif()
 
   if(NOT LLDB_SKIP_STRIP)
 # Strip distribution binary with -ST (removing debug symbol table entries 
and

diff  --git a/lldb/cmake/modules/LLDBConfig.cmake 
b/lldb/cmake/modules/LLDBConfig.cmake
index 2fdf1502d0559..b62cd7d24438f 100644
--- a/lldb/cmake/modules/LLDBConfig.cmake
+++ b/lldb/cmake/modules/LLDBConfig.cmake
@@ -65,6 +65,7 @@ option(LLDB_BUILD_FRAMEWORK "Build LLDB.framework (Darwin 
only)" OFF)
 option(LLDB_NO_INSTALL_DEFAULT_RPATH "Disable default RPATH settings in 
binaries" OFF)
 option(LLDB_USE_SYSTEM_DEBUGSERVER "Use the system's debugserver for testing 
(Darwin only)." OFF)
 option(LLDB_SKIP_STRIP "Whether to skip stripping of binaries when installing 
lldb." OFF)
+option(LLDB_SKIP_DSYM "Whether to skip generating a dSYM when installing 
lldb." OFF)
 
 if (LLDB_USE_SYSTEM_DEBUGSERVER)
   # The custom target for the system debugserver has no install target, so we



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

[Lldb-commits] [PATCH] D103107: [lldb] Remove cache in get_demangled_name_without_arguments

2021-05-26 Thread Raphael Isemann via Phabricator via lldb-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd28bc54ff44a: [lldb] Remove cache in 
get_demangled_name_without_arguments (authored by teemperor).
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103107/new/

https://reviews.llvm.org/D103107

Files:
  lldb/source/Core/Mangled.cpp


Index: lldb/source/Core/Mangled.cpp
===
--- lldb/source/Core/Mangled.cpp
+++ lldb/source/Core/Mangled.cpp
@@ -35,26 +35,8 @@
   return Mangled::GetManglingScheme(s) != Mangled::eManglingSchemeNone;
 }
 
-static ConstString 
-get_demangled_name_without_arguments(ConstString mangled,
- ConstString demangled) {
-  // This pair is 
-  static std::pair
-  g_most_recent_mangled_to_name_sans_args;
-
-  // Need to have the mangled & demangled names we're currently examining as
-  // statics so we can return a const ref to them at the end of the func if we
-  // don't have anything better.
-  static ConstString g_last_mangled;
-  static ConstString g_last_demangled;
-
-  if (mangled && g_most_recent_mangled_to_name_sans_args.first == mangled) {
-return g_most_recent_mangled_to_name_sans_args.second;
-  }
-
-  g_last_demangled = demangled;
-  g_last_mangled = mangled;
-
+static ConstString GetDemangledNameWithoutArguments(ConstString mangled,
+ConstString demangled) {
   const char *mangled_name_cstr = mangled.GetCString();
 
   if (demangled && mangled_name_cstr && mangled_name_cstr[0]) {
@@ -73,17 +55,13 @@
 if (!cxx_method.GetContext().empty())
   shortname = cxx_method.GetContext().str() + "::";
 shortname += cxx_method.GetBasename().str();
-ConstString result(shortname.c_str());
-g_most_recent_mangled_to_name_sans_args.first = mangled;
-g_most_recent_mangled_to_name_sans_args.second = result;
-return g_most_recent_mangled_to_name_sans_args.second;
+return ConstString(shortname);
   }
 }
   }
-
   if (demangled)
-return g_last_demangled;
-  return g_last_mangled;
+return demangled;
+  return mangled;
 }
 
 #pragma mark Mangled
@@ -347,7 +325,7 @@
   ConstString demangled = GetDemangledName();
 
   if (preference == ePreferDemangledWithoutArguments) {
-return get_demangled_name_without_arguments(m_mangled, demangled);
+return GetDemangledNameWithoutArguments(m_mangled, demangled);
   }
   if (preference == ePreferDemangled) {
 // Call the accessor to make sure we get a demangled name in case it hasn't


Index: lldb/source/Core/Mangled.cpp
===
--- lldb/source/Core/Mangled.cpp
+++ lldb/source/Core/Mangled.cpp
@@ -35,26 +35,8 @@
   return Mangled::GetManglingScheme(s) != Mangled::eManglingSchemeNone;
 }
 
-static ConstString 
-get_demangled_name_without_arguments(ConstString mangled,
- ConstString demangled) {
-  // This pair is 
-  static std::pair
-  g_most_recent_mangled_to_name_sans_args;
-
-  // Need to have the mangled & demangled names we're currently examining as
-  // statics so we can return a const ref to them at the end of the func if we
-  // don't have anything better.
-  static ConstString g_last_mangled;
-  static ConstString g_last_demangled;
-
-  if (mangled && g_most_recent_mangled_to_name_sans_args.first == mangled) {
-return g_most_recent_mangled_to_name_sans_args.second;
-  }
-
-  g_last_demangled = demangled;
-  g_last_mangled = mangled;
-
+static ConstString GetDemangledNameWithoutArguments(ConstString mangled,
+ConstString demangled) {
   const char *mangled_name_cstr = mangled.GetCString();
 
   if (demangled && mangled_name_cstr && mangled_name_cstr[0]) {
@@ -73,17 +55,13 @@
 if (!cxx_method.GetContext().empty())
   shortname = cxx_method.GetContext().str() + "::";
 shortname += cxx_method.GetBasename().str();
-ConstString result(shortname.c_str());
-g_most_recent_mangled_to_name_sans_args.first = mangled;
-g_most_recent_mangled_to_name_sans_args.second = result;
-return g_most_recent_mangled_to_name_sans_args.second;
+return ConstString(shortname);
   }
 }
   }
-
   if (demangled)
-return g_last_demangled;
-  return g_last_mangled;
+return demangled;
+  return mangled;
 }
 
 #pragma mark Mangled
@@ -347,7 +325,7 @@
   ConstString demangled = GetDemangledName();
 
   if (preference == ePreferDemangledWithoutArguments) {
-return get_demangled_name_without_arguments(m_mangled, demangled);
+return GetDemangledNameWithoutArguments(m_mangled, demangled);
   }
   if (preference == ePreferDemangled) {
 // Call the accessor to make sure we g

[Lldb-commits] [lldb] d28bc54 - [lldb] Remove cache in get_demangled_name_without_arguments

2021-05-26 Thread Raphael Isemann via lldb-commits


Author: Raphael Isemann
Date: 2021-05-26T18:27:40+02:00
New Revision: d28bc54ff44aad7b080177ef85764d7c5444f031

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

LOG: [lldb] Remove cache in get_demangled_name_without_arguments

This function has a single-value caching based on function local static 
variables.

This causes two problems:

* There is no synchronization, so this function randomly returns the demangled
  name of other functions that are demangled at the same time.
* The 1-element cache is not very effective (the cache rate is around 0% when
  running the LLDB test suite that calls this function around 30k times).

I would propose just removing it.

To prevent anyone else the git archeology: the static result variables were
originally added as this returned a ConstString reference, but that has since
been changed so that this returns by value.

Reviewed By: #lldb, JDevlieghere, shafik

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

Added: 


Modified: 
lldb/source/Core/Mangled.cpp

Removed: 




diff  --git a/lldb/source/Core/Mangled.cpp b/lldb/source/Core/Mangled.cpp
index 3919cb440ab40..82cabc0300113 100644
--- a/lldb/source/Core/Mangled.cpp
+++ b/lldb/source/Core/Mangled.cpp
@@ -35,26 +35,8 @@ static inline bool cstring_is_mangled(llvm::StringRef s) {
   return Mangled::GetManglingScheme(s) != Mangled::eManglingSchemeNone;
 }
 
-static ConstString 
-get_demangled_name_without_arguments(ConstString mangled,
- ConstString demangled) {
-  // This pair is 
-  static std::pair
-  g_most_recent_mangled_to_name_sans_args;
-
-  // Need to have the mangled & demangled names we're currently examining as
-  // statics so we can return a const ref to them at the end of the func if we
-  // don't have anything better.
-  static ConstString g_last_mangled;
-  static ConstString g_last_demangled;
-
-  if (mangled && g_most_recent_mangled_to_name_sans_args.first == mangled) {
-return g_most_recent_mangled_to_name_sans_args.second;
-  }
-
-  g_last_demangled = demangled;
-  g_last_mangled = mangled;
-
+static ConstString GetDemangledNameWithoutArguments(ConstString mangled,
+ConstString demangled) {
   const char *mangled_name_cstr = mangled.GetCString();
 
   if (demangled && mangled_name_cstr && mangled_name_cstr[0]) {
@@ -73,17 +55,13 @@ get_demangled_name_without_arguments(ConstString mangled,
 if (!cxx_method.GetContext().empty())
   shortname = cxx_method.GetContext().str() + "::";
 shortname += cxx_method.GetBasename().str();
-ConstString result(shortname.c_str());
-g_most_recent_mangled_to_name_sans_args.first = mangled;
-g_most_recent_mangled_to_name_sans_args.second = result;
-return g_most_recent_mangled_to_name_sans_args.second;
+return ConstString(shortname);
   }
 }
   }
-
   if (demangled)
-return g_last_demangled;
-  return g_last_mangled;
+return demangled;
+  return mangled;
 }
 
 #pragma mark Mangled
@@ -347,7 +325,7 @@ ConstString Mangled::GetName(Mangled::NamePreference 
preference) const {
   ConstString demangled = GetDemangledName();
 
   if (preference == ePreferDemangledWithoutArguments) {
-return get_demangled_name_without_arguments(m_mangled, demangled);
+return GetDemangledNameWithoutArguments(m_mangled, demangled);
   }
   if (preference == ePreferDemangled) {
 // Call the accessor to make sure we get a demangled name in case it hasn't



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

[Lldb-commits] [PATCH] D103172: [lldb][NFC] Allow range-based for loops over DWARFDIE's children

2021-05-26 Thread Raphael Isemann via Phabricator via lldb-commits

teemperor created this revision.
teemperor added a reviewer: LLDB.
teemperor added a project: LLDB.
Herald added a subscriber: JDevlieghere.
Herald added a reviewer: shafik.
teemperor requested review of this revision.

This patch adds the ability to get a DWARFDIE's children as an LLVM range.

This way we can use for range loops to iterate over them and we can use
LLVM's algorithms like `llvm::all_of` to query all children.

The implementation has to do some small shenanigans as the iterator
needs to store a DWARFDIE, but a DWARFDIE container is also a DWARFDIE
so it can't return the iterator by value. I just made the `children` getter a
templated function to avoid the cyclic dependency.


https://reviews.llvm.org/D103172

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -360,8 +360,7 @@
   }
 }
 
-for (DWARFDIE child_die = die.GetFirstChild(); child_die.IsValid();
- child_die = child_die.GetSibling()) {
+for (DWARFDIE child_die : die.children()) {
   GetTypes(child_die, min_die_offset, max_die_offset, type_mask, type_set);
 }
   }
@@ -985,8 +984,7 @@
   if (!die)
 return false;
 
-  for (DWARFDIE child_die = die.GetFirstChild(); child_die;
-   child_die = child_die.GetSibling()) {
+  for (DWARFDIE child_die : die.children()) {
 if (child_die.Tag() != DW_TAG_imported_declaration)
   continue;
 
@@ -1245,8 +1243,7 @@
 
 bool SymbolFileDWARF::ClassOrStructIsVirtual(const DWARFDIE &parent_die) {
   if (parent_die) {
-for (DWARFDIE die = parent_die.GetFirstChild(); die;
- die = die.GetSibling()) {
+for (DWARFDIE die : parent_die.children()) {
   dw_tag_t tag = die.Tag();
   bool check_virtuality = false;
   switch (tag) {
@@ -3419,8 +3416,7 @@
 // Give the concrete function die specified by "func_die_offset", find the
 // concrete block whose DW_AT_specification or DW_AT_abstract_origin points
 // to "spec_block_die_offset"
-for (DWARFDIE child_die = die.GetFirstChild(); child_die;
- child_die = child_die.GetSibling()) {
+for (DWARFDIE child_die : die.children()) {
   DWARFDIE result_die =
   FindBlockContainingSpecification(child_die, spec_block_die_offset);
   if (result_die)
@@ -3549,8 +3545,7 @@
 static CallSiteParameterArray
 CollectCallSiteParameters(ModuleSP module, DWARFDIE call_site_die) {
   CallSiteParameterArray parameters;
-  for (DWARFDIE child = call_site_die.GetFirstChild(); child.IsValid();
-   child = child.GetSibling()) {
+  for (DWARFDIE child : call_site_die.children()) {
 if (child.Tag() != DW_TAG_call_site_parameter &&
 child.Tag() != DW_TAG_GNU_call_site_parameter)
   continue;
@@ -3615,8 +3610,7 @@
   // For now, assume that all entries are nested directly under the subprogram
   // (this is the kind of DWARF LLVM produces) and parse them eagerly.
   std::vector> call_edges;
-  for (DWARFDIE child = function_die.GetFirstChild(); child.IsValid();
-   child = child.GetSibling()) {
+  for (DWARFDIE child : function_die.children()) {
 if (child.Tag() != DW_TAG_call_site && child.Tag() != DW_TAG_GNU_call_site)
   continue;
 
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h
@@ -11,9 +11,11 @@
 
 #include "DWARFBaseDIE.h"
 #include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/iterator_range.h"
 
 class DWARFDIE : public DWARFBaseDIE {
 public:
+  class child_iterator;
   using DWARFBaseDIE::DWARFBaseDIE;
 
   // Tests
@@ -88,6 +90,47 @@
 int &decl_line, int &decl_column, int &call_file,
 int &call_line, int &call_column,
 lldb_private::DWARFExpression *frame_base) const;
+  /// The range of all the children of this DIE.
+  ///
+  /// This is a template just because child_iterator is not completely defined
+  /// at this point.
+  template 
+  llvm::iterator_range children() const {
+return llvm::make_range(T(*this), T());
+  }
+};
+
+class DWARFDIE::child_iterator
+: public llvm::iterator_facade_base {
+  /// The current child or an invalid DWARFDie.
+  DWARFDIE m_die;
+
+public:
+  child_iterator() = default;
+  child_iterator(const DWARFDIE &parent) : m_die(parent.GetFirstChild()) {}
+  bool operator==(const child_iterator &it) const {
+// DWARFDIE's operator== differentiates between an invalid DWARFDIE that
+// has a CU but no DIE and one

[Lldb-commits] [PATCH] D103124: [lldb] add LLDB_SKIP_DSYM option

2021-05-26 Thread Richard Howell via Phabricator via lldb-commits

rmaz added a comment.

In D103124#2780955 , @smeenai wrote:

> Swift's LLDB fork has a TODO for this :) CC @sgraenitz, who added that TODO.
>
> LGTM. Do you need this to be committed for you?

If you could, thanks


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103124/new/

https://reviews.llvm.org/D103124

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

[Lldb-commits] [PATCH] D101361: [LLDB] Support AArch64/Linux watchpoint on tagged addresses

2021-05-26 Thread Muhammad Omair Javaid via Phabricator via lldb-commits

omjavaid added a comment.

@labath @mgorny any comments on this rev?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101361/new/

https://reviews.llvm.org/D101361

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

[Lldb-commits] [PATCH] D102757: [lldb] Remove non address bits when looking up memory regions

2021-05-26 Thread Muhammad Omair Javaid via Phabricator via lldb-commits

omjavaid added a comment.

In D102757#2781677 , @DavidSpickett 
wrote:

> In D102757#2781561 , @omjavaid 
> wrote:
>
>> Now that we are stripping away top byte is there any information that may be 
>> useful for the remote side and we are removing that on the host side. I am 
>> thinking why we should strip top byte on host side rather than making it the 
>> responsibility of the remote end?
>
> I don't think there'd be anything in there the remote needs. Not for 
> `qMemoryRegionInfo`.
>
> lldb-server will need to remove memory tags somehow anyway (because the tag 
> packet spec says you can send tagged addresses) so we could have it do all of 
> it. My unknown there is "non remote" kinda targets like ELF cores or 
> minidumps, does using the ABI for just those get for those targets get messy.

This looks ok but keep in mind it has effect on ProcessWinodws and Minidump 
that we are not currently testing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102757/new/

https://reviews.llvm.org/D102757

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

[Lldb-commits] [PATCH] D102757: [lldb] Remove non address bits when looking up memory regions

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett added a comment.

One thing that you might think of would be the top bits set for kernel 
alloations. However if we're using the masks and TBI correctly those will be 
left intact.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102757/new/

https://reviews.llvm.org/D102757

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

[Lldb-commits] [PATCH] D102757: [lldb] Remove non address bits when looking up memory regions

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett added a comment.

In D102757#2781561 , @omjavaid wrote:

> Now that we are stripping away top byte is there any information that may be 
> useful for the remote side and we are removing that on the host side. I am 
> thinking why we should strip top byte on host side rather than making it the 
> responsibility of the remote end?

I don't think there'd be anything in there the remote needs. Not for 
`qMemoryRegionInfo`.

lldb-server will need to remove memory tags somehow anyway (because the tag 
packet spec says you can send tagged addresses) so we could have it do all of 
it. My unknown there is "non remote" kinda targets like ELF cores or minidumps, 
does using the ABI for just those get messy.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102757/new/

https://reviews.llvm.org/D102757

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

[Lldb-commits] [PATCH] D97285: [lldb][AArch64] Add "memory tag read" command

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett updated this revision to Diff 347909.
DavidSpickett added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97285/new/

https://reviews.llvm.org/D97285

Files:
  lldb/source/Commands/CMakeLists.txt
  lldb/source/Commands/CommandObjectMemory.cpp
  lldb/source/Commands/CommandObjectMemoryTag.cpp
  lldb/source/Commands/CommandObjectMemoryTag.h
  lldb/test/API/functionalities/memory/tag/Makefile
  lldb/test/API/functionalities/memory/tag/TestMemoryTag.py
  lldb/test/API/functionalities/memory/tag/main.cpp
  lldb/test/API/linux/aarch64/mte_tag_read/Makefile
  lldb/test/API/linux/aarch64/mte_tag_read/TestAArch64LinuxMTEMemoryTagRead.py
  lldb/test/API/linux/aarch64/mte_tag_read/main.c

Index: lldb/test/API/linux/aarch64/mte_tag_read/main.c
===
--- /dev/null
+++ lldb/test/API/linux/aarch64/mte_tag_read/main.c
@@ -0,0 +1,77 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int main(int argc, char const *argv[]) {
+  // We assume that the test runner has checked we're on an MTE system
+
+  if (prctl(PR_SET_TAGGED_ADDR_CTRL,
+PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC |
+// Allow all tags to be generated by the addg
+// instruction __arm_mte_increment_tag produces.
+(0x << PR_MTE_TAG_SHIFT),
+0, 0, 0)) {
+return 1;
+  }
+
+  size_t page_size = sysconf(_SC_PAGESIZE);
+
+  // Allocate memory with MTE
+  // We ask for two pages. One is read only so that we get
+  // 2 mappings in /proc/.../smaps so we can check reading
+  // a range across mappings.
+  // The first allocation will start at the highest address,
+  // so we allocate buf2 first to get:
+  //  | buf | buf2 | 
+  int prot = PROT_READ | PROT_MTE;
+  int flags = MAP_PRIVATE | MAP_ANONYMOUS;
+
+  char *buf2 = mmap(0, page_size, prot, flags, -1, 0);
+  if (buf2 == MAP_FAILED)
+return 1;
+
+  // Writeable so we can set tags on it later
+  char *buf = mmap(0, page_size, prot | PROT_WRITE, flags, -1, 0);
+  if (buf == MAP_FAILED)
+return 1;
+
+  // We expect the mappings to be next to each other
+  if (buf2 - buf != page_size)
+return 1;
+
+  // And without MTE
+  char *non_mte_buf = mmap(0, page_size, PROT_READ | PROT_WRITE, flags, -1, 0);
+  if (non_mte_buf == MAP_FAILED)
+return 1;
+
+  // Set incrementing tags until end of the first page
+  char *tagged_ptr = buf;
+  // This ignores tag bits when subtracting the addresses
+  while (__arm_mte_ptrdiff(tagged_ptr, buf) < page_size) {
+// Set the allocation tag for this location
+__arm_mte_set_tag(tagged_ptr);
+// + 16 for 16 byte granules
+// Earlier we allowed all tag values, so this will give us an
+// incrementing pattern 0-0xF wrapping back to 0.
+tagged_ptr = __arm_mte_increment_tag(tagged_ptr + 16, 1);
+  }
+
+  // Tag the original pointer with 9
+  buf = __arm_mte_create_random_tag(buf, ~(1 << 9));
+  // A different tag so that buf_alt_tag > buf if you don't handle the tag
+  char *buf_alt_tag = __arm_mte_create_random_tag(buf, ~(1 << 10));
+
+  // lldb should be removing the whole top byte, not just the tags.
+  // So fill 63-60 with something non zero so we'll fail if we only remove tags.
+#define SET_TOP_NIBBLE(ptr) (char *)((size_t)(ptr) | (0xA << 60))
+  buf = SET_TOP_NIBBLE(buf);
+  buf_alt_tag = SET_TOP_NIBBLE(buf_alt_tag);
+  buf2 = SET_TOP_NIBBLE(buf2);
+
+  // Breakpoint here
+  return 0;
+}
Index: lldb/test/API/linux/aarch64/mte_tag_read/TestAArch64LinuxMTEMemoryTagRead.py
===
--- /dev/null
+++ lldb/test/API/linux/aarch64/mte_tag_read/TestAArch64LinuxMTEMemoryTagRead.py
@@ -0,0 +1,126 @@
+"""
+Test "memory tag read" command on AArch64 Linux with MTE.
+"""
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class AArch64LinuxMTEMemoryTagReadTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+NO_DEBUG_INFO_TESTCASE = True
+
+@skipUnlessArch("aarch64")
+@skipUnlessPlatform(["linux"])
+@skipUnlessAArch64MTELinuxCompiler
+def test_mte_tag_read(self):
+if not self.isAArch64MTE():
+self.skipTest('Target must support MTE.')
+
+self.build()
+self.runCmd("file " + self.getBuildArtifact("a.out"), CURRENT_EXECUTABLE_SET)
+
+lldbutil.run_break_set_by_file_and_line(self, "main.c",
+line_number('main.c', '// Breakpoint here'),
+num_expected_locations=1)
+
+self.runCmd("run", RUN_SUCCEEDED)
+
+if self.process().GetState() == lldb.eStateExited:
+self.fail("Test program failed to run.")
+
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs=['stopped',
+ 'stop reason = breakpoint'])
+
+#

[Lldb-commits] [PATCH] D95602: [lldb][AArch64] Add MTE memory tag reading to lldb

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett updated this revision to Diff 347906.
DavidSpickett added a comment.

Rebase, fix up `SendPacketAndWaitForResponse` use.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95602/new/

https://reviews.llvm.org/D95602

Files:
  lldb/include/lldb/Core/Architecture.h
  lldb/include/lldb/Target/Process.h
  lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp
  lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.h
  lldb/source/Plugins/Architecture/AArch64/CMakeLists.txt
  lldb/source/Plugins/Architecture/CMakeLists.txt
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/source/Target/Process.cpp
  lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp

Index: lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
===
--- lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+++ lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
@@ -466,3 +466,68 @@
   EXPECT_EQ(llvm::None, GetQOffsets("TextSeg=0x1234"));
   EXPECT_EQ(llvm::None, GetQOffsets("TextSeg=12345678123456789"));
 }
+
+static void
+check_qmemtags(TestClient &client, MockServer &server, size_t read_len,
+   const char *packet, llvm::StringRef response,
+   llvm::Optional> expected_tag_data) {
+  const auto &ReadMemoryTags = [&](size_t len, const char *packet,
+   llvm::StringRef response) {
+std::future result = std::async(std::launch::async, [&] {
+  return client.ReadMemoryTags(0xDEF0, read_len, 1);
+});
+
+HandlePacket(server, packet, response);
+return result.get();
+  };
+
+  auto result = ReadMemoryTags(0, packet, response);
+  if (expected_tag_data) {
+ASSERT_TRUE(result);
+llvm::ArrayRef expected(*expected_tag_data);
+llvm::ArrayRef got = result->GetData();
+ASSERT_THAT(expected, testing::ContainerEq(got));
+  } else {
+ASSERT_FALSE(result);
+  }
+}
+
+TEST_F(GDBRemoteCommunicationClientTest, ReadMemoryTags) {
+  // Zero length reads are valid
+  check_qmemtags(client, server, 0, "qMemTags:def0,0:1", "m",
+ std::vector{});
+
+  // The client layer does not check the length of the received data.
+  // All we need is the "m" and for the decode to use all of the chars
+  check_qmemtags(client, server, 32, "qMemTags:def0,20:1", "m09",
+ std::vector{0x9});
+
+  // Zero length response is fine as long as the "m" is present
+  check_qmemtags(client, server, 0, "qMemTags:def0,0:1", "m",
+ std::vector{});
+
+  // Normal responses
+  check_qmemtags(client, server, 16, "qMemTags:def0,10:1", "m66",
+ std::vector{0x66});
+  check_qmemtags(client, server, 32, "qMemTags:def0,20:1", "m0102",
+ std::vector{0x1, 0x2});
+
+  // Empty response is an error
+  check_qmemtags(client, server, 17, "qMemTags:def0,11:1", "", llvm::None);
+  // Usual error response
+  check_qmemtags(client, server, 17, "qMemTags:def0,11:1", "E01", llvm::None);
+  // Leading m missing
+  check_qmemtags(client, server, 17, "qMemTags:def0,11:1", "01", llvm::None);
+  // Anything other than m is an error
+  check_qmemtags(client, server, 17, "qMemTags:def0,11:1", "z01", llvm::None);
+  // Decoding tag data doesn't use all the chars in the packet
+  check_qmemtags(client, server, 32, "qMemTags:def0,20:1", "m09zz", llvm::None);
+  // Data that is not hex bytes
+  check_qmemtags(client, server, 32, "qMemTags:def0,20:1", "mhello",
+ llvm::None);
+  // Data is not a complete hex char
+  check_qmemtags(client, server, 32, "qMemTags:def0,20:1", "m9", llvm::None);
+  // Data has a trailing hex char
+  check_qmemtags(client, server, 32, "qMemTags:def0,20:1", "m01020",
+ llvm::None);
+}
Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -6067,3 +6067,84 @@
 
   return false;
 }
+
+llvm::Expected
+Process::GetMemoryTagManager(lldb::addr_t addr, lldb::addr_t end_addr) {
+  Architecture *arch = GetTarget().GetArchitecturePlugin();
+  const MemoryTagManager *tag_manager =
+  arch ? arch->GetMemoryTagManager() : nullptr;
+  if (!arch || !tag_manager) {
+return llvm::createStringError(
+llvm::inconvertibleErrorCode(),
+"This architecture does not support memory tagging",
+GetPluginName().GetCString());
+  }
+
+  if (!SupportsMemoryTagging()) {
+return llvm::createStringError(llvm::inconvertibleErrorCode(),
+   "Process does not support memory tagging");
+  }
+
+  ptrdiff_t len = tag_mana

[Lldb-commits] [PATCH] D102757: [lldb] Remove non address bits when looking up memory regions

2021-05-26 Thread Muhammad Omair Javaid via Phabricator via lldb-commits

omjavaid added a comment.

Now that we are stripping away top byte is there any information that may be 
useful for the remote side and we are removing that on the host side. I am 
thinking why we should strip top byte on host side rather than making it the 
responsibility of the remote end?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102757/new/

https://reviews.llvm.org/D102757

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

[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett updated this revision to Diff 347899.
DavidSpickett added a comment.

I was looking at the wrong file, this adds the header.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95601/new/

https://reviews.llvm.org/D95601

Files:
  lldb/include/lldb/Host/common/NativeProcessProtocol.h
  lldb/include/lldb/Host/linux/Ptrace.h
  lldb/include/lldb/Utility/StringExtractorGDBRemote.h
  lldb/source/Host/common/NativeProcessProtocol.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
  lldb/source/Utility/StringExtractorGDBRemote.cpp
  lldb/test/API/tools/lldb-server/memory-tagging/Makefile
  lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
  lldb/test/API/tools/lldb-server/memory-tagging/main.c

Index: lldb/test/API/tools/lldb-server/memory-tagging/main.c
===
--- /dev/null
+++ lldb/test/API/tools/lldb-server/memory-tagging/main.c
@@ -0,0 +1,55 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int print_result(char *ptr) {
+  // Page size allows the test to try reading off of the end of the page
+  printf("buffer: %p page_size: 0x%x\n", ptr, sysconf(_SC_PAGESIZE));
+
+  // Exit after some time, so we don't leave a zombie process
+  // if the test framework lost track of us.
+  sleep(60);
+  return 0;
+}
+
+int main(int argc, char const *argv[]) {
+  if (prctl(PR_SET_TAGGED_ADDR_CTRL,
+PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC |
+// Allow all tags to be generated by the addg
+// instruction __arm_mte_increment_tag produces.
+(0x << PR_MTE_TAG_SHIFT),
+0, 0, 0)) {
+return print_result(NULL);
+  }
+
+  size_t page_size = sysconf(_SC_PAGESIZE);
+  char *buf = mmap(0, page_size, PROT_READ | PROT_WRITE | PROT_MTE,
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+  if (buf == MAP_FAILED)
+return print_result(NULL);
+
+  // Set incrementing tags until end of the page
+  char *tagged_ptr = buf;
+  // This intrinsic treats the addresses as if they were untagged
+  while (__arm_mte_ptrdiff(tagged_ptr, buf) < page_size) {
+// This sets the allocation tag
+__arm_mte_set_tag(tagged_ptr);
+// Set the tag of the next granule (hence +16) to the next
+// tag value. Returns a new pointer with the new logical tag.
+// Tag values wrap at 0xF so it'll cycle.
+tagged_ptr = __arm_mte_increment_tag(tagged_ptr + 16, 1);
+  }
+
+  // lldb-server should be removing the top byte from addresses passed
+  // to ptrace. So put some random bits in there.
+  // ptrace expects you to remove them but it can still succeed if you
+  // don't. So this isn't proof that we're removing them, it's just a
+  // smoke test in case something didn't account for them.
+  buf = (char *)((size_t)buf | ((size_t)0xAA << 56));
+  return print_result(buf);
+}
Index: lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
===
--- /dev/null
+++ lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
@@ -0,0 +1,116 @@
+import gdbremote_testcase
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestGdbRemoteMemoryTagging(gdbremote_testcase.GdbRemoteTestCaseBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def check_qmemtags_response(self, body, expected):
+self.test_sequence.add_log_lines(["read packet: $qMemTags:{}#00".format(body),
+  "send packet: ${}#00".format(expected),
+  ],
+ True)
+self.expect_gdbremote_sequence()
+
+@skipUnlessArch("aarch64")
+@skipUnlessPlatform(["linux"])
+@skipUnlessAArch64MTELinuxCompiler
+def test_qmemtags_packets(self):
+""" Test that qMemTags packets are parsed correctly and/or rejected. """
+
+self.build()
+self.set_inferior_startup_launch()
+procs = self.prep_debug_monitor_and_inferior()
+
+# Run the process
+self.test_sequence.add_log_lines(
+[
+# Start running after initial stop
+"read packet: $c#63",
+		# Match the address of the MTE page
+{"type": "output_match",
+ "regex": self.maybe_strict_output_regex(r"buffer: (.+) page_size: (.+)\r\n"),
+

[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett updated this revision to Diff 347898.
DavidSpickett added a comment.

Rebase, which brings in the header pcc mentioned.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95601/new/

https://reviews.llvm.org/D95601

Files:
  lldb/include/lldb/Host/common/NativeProcessProtocol.h
  lldb/include/lldb/Host/linux/Ptrace.h
  lldb/include/lldb/Utility/StringExtractorGDBRemote.h
  lldb/source/Host/common/NativeProcessProtocol.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
  lldb/source/Utility/StringExtractorGDBRemote.cpp
  lldb/test/API/tools/lldb-server/memory-tagging/Makefile
  lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
  lldb/test/API/tools/lldb-server/memory-tagging/main.c

Index: lldb/test/API/tools/lldb-server/memory-tagging/main.c
===
--- /dev/null
+++ lldb/test/API/tools/lldb-server/memory-tagging/main.c
@@ -0,0 +1,55 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int print_result(char *ptr) {
+  // Page size allows the test to try reading off of the end of the page
+  printf("buffer: %p page_size: 0x%x\n", ptr, sysconf(_SC_PAGESIZE));
+
+  // Exit after some time, so we don't leave a zombie process
+  // if the test framework lost track of us.
+  sleep(60);
+  return 0;
+}
+
+int main(int argc, char const *argv[]) {
+  if (prctl(PR_SET_TAGGED_ADDR_CTRL,
+PR_TAGGED_ADDR_ENABLE | PR_MTE_TCF_SYNC |
+// Allow all tags to be generated by the addg
+// instruction __arm_mte_increment_tag produces.
+(0x << PR_MTE_TAG_SHIFT),
+0, 0, 0)) {
+return print_result(NULL);
+  }
+
+  size_t page_size = sysconf(_SC_PAGESIZE);
+  char *buf = mmap(0, page_size, PROT_READ | PROT_WRITE | PROT_MTE,
+   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+  if (buf == MAP_FAILED)
+return print_result(NULL);
+
+  // Set incrementing tags until end of the page
+  char *tagged_ptr = buf;
+  // This intrinsic treats the addresses as if they were untagged
+  while (__arm_mte_ptrdiff(tagged_ptr, buf) < page_size) {
+// This sets the allocation tag
+__arm_mte_set_tag(tagged_ptr);
+// Set the tag of the next granule (hence +16) to the next
+// tag value. Returns a new pointer with the new logical tag.
+// Tag values wrap at 0xF so it'll cycle.
+tagged_ptr = __arm_mte_increment_tag(tagged_ptr + 16, 1);
+  }
+
+  // lldb-server should be removing the top byte from addresses passed
+  // to ptrace. So put some random bits in there.
+  // ptrace expects you to remove them but it can still succeed if you
+  // don't. So this isn't proof that we're removing them, it's just a
+  // smoke test in case something didn't account for them.
+  buf = (char *)((size_t)buf | ((size_t)0xAA << 56));
+  return print_result(buf);
+}
Index: lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
===
--- /dev/null
+++ lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py
@@ -0,0 +1,116 @@
+import gdbremote_testcase
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestGdbRemoteMemoryTagging(gdbremote_testcase.GdbRemoteTestCaseBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def check_qmemtags_response(self, body, expected):
+self.test_sequence.add_log_lines(["read packet: $qMemTags:{}#00".format(body),
+  "send packet: ${}#00".format(expected),
+  ],
+ True)
+self.expect_gdbremote_sequence()
+
+@skipUnlessArch("aarch64")
+@skipUnlessPlatform(["linux"])
+@skipUnlessAArch64MTELinuxCompiler
+def test_qmemtags_packets(self):
+""" Test that qMemTags packets are parsed correctly and/or rejected. """
+
+self.build()
+self.set_inferior_startup_launch()
+procs = self.prep_debug_monitor_and_inferior()
+
+# Run the process
+self.test_sequence.add_log_lines(
+[
+# Start running after initial stop
+"read packet: $c#63",
+		# Match the address of the MTE page
+{"type": "output_match",
+ "regex": self.maybe_strict_output_regex(r"buffer: (.+) page_size: (.+)\r\n"),
+

[Lldb-commits] [PATCH] D97282: [lldb][AArch64] Add memory-tagging qSupported feature

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett updated this revision to Diff 347896.
DavidSpickett added a subscriber: pcc.
DavidSpickett added a comment.

Rebase, which brings in the include @pcc mentioned.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97282/new/

https://reviews.llvm.org/D97282

Files:
  lldb/include/lldb/Host/common/NativeProcessProtocol.h
  lldb/include/lldb/Target/Process.h
  lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/test/API/tools/lldb-server/TestLldbGdbServer.py

Index: lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
===
--- lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
+++ lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
@@ -1025,6 +1025,14 @@
 self.assertEqual(supported_dict.get('fork-events', '-'), '-')
 self.assertEqual(supported_dict.get('vfork-events', '-'), '-')
 
+# We need to be able to self.runCmd to get cpuinfo,
+# which is not possible when using a remote platform.
+@skipIfRemote
+def test_qSupported_memory_tagging(self):
+supported_dict = self.get_qSupported_dict()
+self.assertEqual(supported_dict.get("memory-tagging", '-'),
+ '+' if self.isAArch64MTE() else '-')
+
 @skipIfWindows # No pty support to test any inferior output
 def test_written_M_content_reads_back_correctly(self):
 self.build()
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -235,6 +235,8 @@
   friend class GDBRemoteCommunicationClient;
   friend class GDBRemoteRegisterContext;
 
+  bool SupportsMemoryTagging() override;
+
   /// Broadcaster event bits definitions.
   enum {
 eBroadcastBitAsyncContinue = (1 << 0),
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2768,6 +2768,10 @@
   return 0;
 }
 
+bool ProcessGDBRemote::SupportsMemoryTagging() {
+  return m_gdb_comm.GetMemoryTaggingSupported();
+}
+
 Status ProcessGDBRemote::WriteObjectFile(
 std::vector entries) {
   Status error;
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -3608,6 +3608,8 @@
 ret.push_back("qXfer:auxv:read+");
   if (bool(plugin_features & Extension::libraries_svr4))
 ret.push_back("qXfer:libraries-svr4:read+");
+  if (bool(plugin_features & Extension::memory_tagging))
+ret.push_back("memory-tagging+");
 
   // check for client features
   m_extensions_supported = {};
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
@@ -451,6 +451,8 @@
 
   bool GetSharedCacheInfoSupported();
 
+  bool GetMemoryTaggingSupported();
+
   /// Use qOffsets to query the offset used when relocating the target
   /// executable. If successful, the returned structure will contain at least
   /// one value in the offsets field.
@@ -558,6 +560,7 @@
   LazyBool m_supports_QPassSignals;
   LazyBool m_supports_error_string_reply;
   LazyBool m_supports_multiprocess;
+  LazyBool m_supports_memory_tagging;
 
   bool m_supports_qProcessInfoPID : 1, m_supports_qfProcessInfo : 1,
   m_supports_qUserName : 1, m_supports_qGroupName : 1,
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -90,6 +90,7 @@
   m_supports_QPassSignals(eLazyBoolCalculate),
   m_supports_error_string_reply(eLazyBoolCalculate),
   m_supports_multiprocess(eLazyBoolCalculate),
+  m_supports_memory_tagging(eLazyBoolCalculate),
   m_supports_qProcessInfoPID(true), m_s

[Lldb-commits] [PATCH] D97281: [lldb][AArch64] Add class for managing memory tags

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett updated this revision to Diff 347893.
DavidSpickett added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97281/new/

https://reviews.llvm.org/D97281

Files:
  lldb/include/lldb/Target/MemoryTagManager.h
  lldb/source/Plugins/Process/Utility/CMakeLists.txt
  lldb/source/Plugins/Process/Utility/MemoryTagManagerAArch64MTE.cpp
  lldb/source/Plugins/Process/Utility/MemoryTagManagerAArch64MTE.h
  lldb/unittests/Process/Utility/CMakeLists.txt
  lldb/unittests/Process/Utility/MemoryTagManagerAArch64MTETest.cpp

Index: lldb/unittests/Process/Utility/MemoryTagManagerAArch64MTETest.cpp
===
--- /dev/null
+++ lldb/unittests/Process/Utility/MemoryTagManagerAArch64MTETest.cpp
@@ -0,0 +1,120 @@
+//===-- MemoryTagManagerAArch64MTETest.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/Process/Utility/MemoryTagManagerAArch64MTE.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+
+TEST(MemoryTagManagerAArch64MTETest, UnpackTagsData) {
+  MemoryTagManagerAArch64MTE manager;
+
+  // Error for insufficient tag data
+  std::vector input;
+  ASSERT_THAT_EXPECTED(
+  manager.UnpackTagsData(input, 2),
+  llvm::FailedWithMessage(
+  "Packed tag data size does not match expected number of tags. "
+  "Expected 2 tag(s) for 2 granules, got 0 tag(s)."));
+
+  // This is out of the valid tag range
+  input.push_back(0x1f);
+  ASSERT_THAT_EXPECTED(
+  manager.UnpackTagsData(input, 1),
+  llvm::FailedWithMessage(
+  "Found tag 0x1f which is > max MTE tag value of 0xf."));
+
+  // MTE tags are 1 per byte
+  input.pop_back();
+  input.push_back(0xe);
+  input.push_back(0xf);
+
+  std::vector expected{0xe, 0xf};
+
+  llvm::Expected> got =
+  manager.UnpackTagsData(input, 2);
+  ASSERT_THAT_EXPECTED(got, llvm::Succeeded());
+  ASSERT_THAT(expected, testing::ContainerEq(*got));
+}
+
+TEST(MemoryTagManagerAArch64MTETest, GetLogicalTag) {
+  MemoryTagManagerAArch64MTE manager;
+
+  // Set surrounding bits to check shift is correct
+  ASSERT_EQ((lldb::addr_t)0, manager.GetLogicalTag(0xe0e0));
+  // Max tag value
+  ASSERT_EQ((lldb::addr_t)0xf, manager.GetLogicalTag(0x0f00));
+  ASSERT_EQ((lldb::addr_t)2, manager.GetLogicalTag(0x0200));
+}
+
+TEST(MemoryTagManagerAArch64MTETest, ExpandToGranule) {
+  MemoryTagManagerAArch64MTE manager;
+  // Reading nothing, no alignment needed
+  ASSERT_EQ(
+  MemoryTagManagerAArch64MTE::TagRange(0, 0),
+  manager.ExpandToGranule(MemoryTagManagerAArch64MTE::TagRange(0, 0)));
+
+  // Ranges with 0 size are unchanged even if address is non 0
+  // (normally 0x1234 would be aligned to 0x1230)
+  ASSERT_EQ(
+  MemoryTagManagerAArch64MTE::TagRange(0x1234, 0),
+  manager.ExpandToGranule(MemoryTagManagerAArch64MTE::TagRange(0x1234, 0)));
+
+  // Ranges already aligned don't change
+  ASSERT_EQ(
+  MemoryTagManagerAArch64MTE::TagRange(0x100, 64),
+  manager.ExpandToGranule(MemoryTagManagerAArch64MTE::TagRange(0x100, 64)));
+
+  // Any read of less than 1 granule is rounded up to reading 1 granule
+  ASSERT_EQ(
+  MemoryTagManagerAArch64MTE::TagRange(0, 16),
+  manager.ExpandToGranule(MemoryTagManagerAArch64MTE::TagRange(0, 1)));
+
+  // Start address is aligned down, and length modified accordingly
+  // Here bytes 8 through 24 straddle 2 granules. So the resulting range starts
+  // at 0 and covers 32 bytes.
+  ASSERT_EQ(
+  MemoryTagManagerAArch64MTE::TagRange(0, 32),
+  manager.ExpandToGranule(MemoryTagManagerAArch64MTE::TagRange(8, 16)));
+
+  // Here only the size of the range needs aligning
+  ASSERT_EQ(
+  MemoryTagManagerAArch64MTE::TagRange(16, 32),
+  manager.ExpandToGranule(MemoryTagManagerAArch64MTE::TagRange(16, 24)));
+
+  // Start and size need aligning here but we only need 1 granule to cover it
+  ASSERT_EQ(
+  MemoryTagManagerAArch64MTE::TagRange(16, 16),
+  manager.ExpandToGranule(MemoryTagManagerAArch64MTE::TagRange(18, 4)));
+}
+
+TEST(MemoryTagManagerAArch64MTETest, RemoveNonAddressBits) {
+  MemoryTagManagerAArch64MTE manager;
+
+  ASSERT_EQ(0, 0);
+  ASSERT_EQ((lldb::addr_t)0x00ffeedd11223344,
+manager.RemoveNonAddressBits(0x00ffeedd11223344));
+  ASSERT_EQ((lldb::addr_t)0x,
+manager.RemoveNonAddressBits(0xFF00));
+  ASSERT_EQ((lldb::addr_t)0x0055,
+manager.RemoveNonAddressBits(0xee55));
+}
+
+TEST(MemoryTagManagerAArch64MTETest, AddressDiff) {
+  MemoryTagManagerAArch64MTE manager;
+

[Lldb-commits] [PATCH] D97282: [lldb][AArch64] Add memory-tagging qSupported feature

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett updated this revision to Diff 347895.
DavidSpickett added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D97282/new/

https://reviews.llvm.org/D97282

Files:
  lldb/include/lldb/Host/common/NativeProcessProtocol.h
  lldb/include/lldb/Target/Process.h
  lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
  lldb/test/API/tools/lldb-server/TestLldbGdbServer.py

Index: lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
===
--- lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
+++ lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
@@ -1025,6 +1025,14 @@
 self.assertEqual(supported_dict.get('fork-events', '-'), '-')
 self.assertEqual(supported_dict.get('vfork-events', '-'), '-')
 
+# We need to be able to self.runCmd to get cpuinfo,
+# which is not possible when using a remote platform.
+@skipIfRemote
+def test_qSupported_memory_tagging(self):
+supported_dict = self.get_qSupported_dict()
+self.assertEqual(supported_dict.get("memory-tagging", '-'),
+ '+' if self.isAArch64MTE() else '-')
+
 @skipIfWindows # No pty support to test any inferior output
 def test_written_M_content_reads_back_correctly(self):
 self.build()
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
@@ -235,6 +235,8 @@
   friend class GDBRemoteCommunicationClient;
   friend class GDBRemoteRegisterContext;
 
+  bool SupportsMemoryTagging() override;
+
   /// Broadcaster event bits definitions.
   enum {
 eBroadcastBitAsyncContinue = (1 << 0),
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2768,6 +2768,10 @@
   return 0;
 }
 
+bool ProcessGDBRemote::SupportsMemoryTagging() {
+  return m_gdb_comm.GetMemoryTaggingSupported();
+}
+
 Status ProcessGDBRemote::WriteObjectFile(
 std::vector entries) {
   Status error;
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -3608,6 +3608,8 @@
 ret.push_back("qXfer:auxv:read+");
   if (bool(plugin_features & Extension::libraries_svr4))
 ret.push_back("qXfer:libraries-svr4:read+");
+  if (bool(plugin_features & Extension::memory_tagging))
+ret.push_back("memory-tagging+");
 
   // check for client features
   m_extensions_supported = {};
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.h
@@ -451,6 +451,8 @@
 
   bool GetSharedCacheInfoSupported();
 
+  bool GetMemoryTaggingSupported();
+
   /// Use qOffsets to query the offset used when relocating the target
   /// executable. If successful, the returned structure will contain at least
   /// one value in the offsets field.
@@ -558,6 +560,7 @@
   LazyBool m_supports_QPassSignals;
   LazyBool m_supports_error_string_reply;
   LazyBool m_supports_multiprocess;
+  LazyBool m_supports_memory_tagging;
 
   bool m_supports_qProcessInfoPID : 1, m_supports_qfProcessInfo : 1,
   m_supports_qUserName : 1, m_supports_qGroupName : 1,
Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
@@ -90,6 +90,7 @@
   m_supports_QPassSignals(eLazyBoolCalculate),
   m_supports_error_string_reply(eLazyBoolCalculate),
   m_supports_multiprocess(eLazyBoolCalculate),
+  m_supports_memory_tagging(eLazyBoolCalculate),
   m_supports_qProcessInfoPID(true), m_supports_qfProcessInfo(true),
   m_supports_qUserName(true), m_supports_qGroupNam

[Lldb-commits] [PATCH] D99944: [LLDB] AArch64 Linux and elf-core PAC stack unwinder support

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett resigned from this revision.
DavidSpickett added a comment.

Resigning to remove my requested changes, if that works. Looks good from my 
point of view.

@labath You had earlier questions about using the register context, and a few 
comments that have gotten disconnected from the original diff somehow. Those 
concerns still relevant?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99944/new/

https://reviews.llvm.org/D99944

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

[Lldb-commits] [PATCH] D99944: [LLDB] AArch64 Linux and elf-core PAC stack unwinder support

2021-05-26 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett added a comment.

I realised my mistake, I thought this was adding a new core file but in fact 
it's using the one you added for the register tests. So now the outfile is 
there the test passes.




Comment at: 
lldb/test/API/functionalities/unwind/aarch64_unwind_pac/TestAArch64UnwindPAC.py:41
+self.assertEqual(frame.GetFunctionName(), backtrace[frame_idx])
+   # Check line number for functions in main.c
+if (frame_idx < 4):

Strange indent here



Comment at: lldb/test/API/functionalities/unwind/aarch64_unwind_pac/main.c:5
+// To enable PAC return address signing compile with following clang arguments:
+// -march=armv8.5-a -mbranch-protection=pac-ret+leaf
+

I'd rather use `armv8.3-a` here just for correctness.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99944/new/

https://reviews.llvm.org/D99944

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

[Lldb-commits] [PATCH] D103210: [lldb] Introduce Language::MethodNameInfo

[Lldb-commits] [PATCH] D103217: Make ignore counts work as "after stop" modifiers so they play nicely with conditions

[Lldb-commits] [PATCH] D103210: [lldb] Introduce Language::MethodNameInfo

[Lldb-commits] [PATCH] D103210: [lldb] Introduce Language::MethodNameInfo

[Lldb-commits] [PATCH] D103209: [lldb] Fix gnu_libstdcpp's update methods

[Lldb-commits] [lldb] 0283abe - [lldb] Fix gnu_libstdcpp's update methods

[Lldb-commits] [PATCH] D103209: [lldb] Fix gnu_libstdcpp's update methods

[Lldb-commits] [PATCH] D103172: [lldb][NFC] Allow range-based for loops over DWARFDIE's children

[Lldb-commits] [PATCH] D103124: [lldb] add LLDB_SKIP_DSYM option

[Lldb-commits] [lldb] 969eefd - [lldb] add LLDB_SKIP_DSYM option

[Lldb-commits] [PATCH] D103107: [lldb] Remove cache in get_demangled_name_without_arguments

[Lldb-commits] [lldb] d28bc54 - [lldb] Remove cache in get_demangled_name_without_arguments

[Lldb-commits] [PATCH] D103172: [lldb][NFC] Allow range-based for loops over DWARFDIE's children

[Lldb-commits] [PATCH] D103124: [lldb] add LLDB_SKIP_DSYM option

[Lldb-commits] [PATCH] D101361: [LLDB] Support AArch64/Linux watchpoint on tagged addresses

[Lldb-commits] [PATCH] D102757: [lldb] Remove non address bits when looking up memory regions

[Lldb-commits] [PATCH] D102757: [lldb] Remove non address bits when looking up memory regions

[Lldb-commits] [PATCH] D102757: [lldb] Remove non address bits when looking up memory regions

[Lldb-commits] [PATCH] D97285: [lldb][AArch64] Add "memory tag read" command

[Lldb-commits] [PATCH] D95602: [lldb][AArch64] Add MTE memory tag reading to lldb

[Lldb-commits] [PATCH] D102757: [lldb] Remove non address bits when looking up memory regions

[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

[Lldb-commits] [PATCH] D97282: [lldb][AArch64] Add memory-tagging qSupported feature

[Lldb-commits] [PATCH] D97281: [lldb][AArch64] Add class for managing memory tags

[Lldb-commits] [PATCH] D97282: [lldb][AArch64] Add memory-tagging qSupported feature

[Lldb-commits] [PATCH] D99944: [LLDB] AArch64 Linux and elf-core PAC stack unwinder support

[Lldb-commits] [PATCH] D99944: [LLDB] AArch64 Linux and elf-core PAC stack unwinder support

28 matches

Site Navigation

Mail list logo

Footer information