date:20200427

[Lldb-commits] [lldb] b58af8d - [lldb] Improve error message when --func-regex parameter for the breakpoint command is invalid

2020-04-27 Thread Raphael Isemann via lldb-commits


Author: Raphael Isemann
Date: 2020-04-27T09:55:06+02:00
New Revision: b58af8d254ee1b1a7d2806b1fdfe295df925748a

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

LOG: [lldb] Improve error message when --func-regex parameter for the 
breakpoint command is invalid

Summary:
Currently the breakpoint command is prompting the user to file a bug report if 
the provided regex is invalid:
```
(lldb) rbreak *foo
error: Function name regular expression could not be compiled: "Inconvertible 
error value. An error has occurred that could not be converted to a known 
std::error_code. Please file a bug. repetition-operator operand invalid"
```

The reason is simply that we are using the wrong StringError constructor (the 
one with the error code as the first parameter
is also printing the string version of the error code, and the inconvertible 
error code is just an invalid place holder code with
that description). Switching the StringError constructor parameters will only 
print the error message we get from the regex
engine when we convert the error into a string.

I checked the rest of the code base and I couldn't find the same issue anywhere 
else.

Fixes rdar://62233561

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: lldb-commits

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

Added: 
lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py

Modified: 
lldb/source/Commands/CommandObjectBreakpoint.cpp
lldb/source/Utility/RegularExpression.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectBreakpoint.cpp 
b/lldb/source/Commands/CommandObjectBreakpoint.cpp
index 3c5d8f087a27..661ebc790354 100644
--- a/lldb/source/Commands/CommandObjectBreakpoint.cpp
+++ b/lldb/source/Commands/CommandObjectBreakpoint.cpp
@@ -620,7 +620,7 @@ class CommandObjectBreakpointSet : public 
CommandObjectParsed {
   RegularExpression regexp(m_options.m_func_regexp);
   if (llvm::Error err = regexp.GetError()) {
 result.AppendErrorWithFormat(
-"Function name regular expression could not be compiled: \"%s\"",
+"Function name regular expression could not be compiled: %s",
 llvm::toString(std::move(err)).c_str());
 result.SetStatus(eReturnStatusFailed);
 return false;

diff  --git a/lldb/source/Utility/RegularExpression.cpp 
b/lldb/source/Utility/RegularExpression.cpp
index 3736a25ef2ac..20bebbfe15f2 100644
--- a/lldb/source/Utility/RegularExpression.cpp
+++ b/lldb/source/Utility/RegularExpression.cpp
@@ -35,7 +35,7 @@ llvm::StringRef RegularExpression::GetText() const { return 
m_regex_text; }
 llvm::Error RegularExpression::GetError() const {
   std::string error;
   if (!m_regex.isValid(error))
-return llvm::make_error(llvm::inconvertibleErrorCode(),
-   error);
+return llvm::make_error(error,
+   llvm::inconvertibleErrorCode());
   return llvm::Error::success();
 }

diff  --git 
a/lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py 
b/lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py
new file mode 100644
index ..a8cfcf2d1d87
--- /dev/null
+++ 
b/lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py
@@ -0,0 +1,14 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+def test_error(self):
+self.expect("breakpoint set --func-regex (", error=True,
+substrs=["error: Function name regular expression could " +
+ "not be compiled: parentheses not balanced"])



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

[Lldb-commits] [PATCH] D78808: [lldb] Improve error message when --func-regex parameter for the breakpoint command is invalid

2020-04-27 Thread Raphael Isemann via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb58af8d254ee: [lldb] Improve error message when --func-regex 
parameter for the breakpoint… (authored by teemperor).
Herald added a project: LLDB.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78808

Files:
  lldb/source/Commands/CommandObjectBreakpoint.cpp
  lldb/source/Utility/RegularExpression.cpp
  lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py


Index: 
lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py
===
--- /dev/null
+++ lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py
@@ -0,0 +1,14 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+def test_error(self):
+self.expect("breakpoint set --func-regex (", error=True,
+substrs=["error: Function name regular expression could " +
+ "not be compiled: parentheses not balanced"])
Index: lldb/source/Utility/RegularExpression.cpp
===
--- lldb/source/Utility/RegularExpression.cpp
+++ lldb/source/Utility/RegularExpression.cpp
@@ -35,7 +35,7 @@
 llvm::Error RegularExpression::GetError() const {
   std::string error;
   if (!m_regex.isValid(error))
-return llvm::make_error(llvm::inconvertibleErrorCode(),
-   error);
+return llvm::make_error(error,
+   llvm::inconvertibleErrorCode());
   return llvm::Error::success();
 }
Index: lldb/source/Commands/CommandObjectBreakpoint.cpp
===
--- lldb/source/Commands/CommandObjectBreakpoint.cpp
+++ lldb/source/Commands/CommandObjectBreakpoint.cpp
@@ -620,7 +620,7 @@
   RegularExpression regexp(m_options.m_func_regexp);
   if (llvm::Error err = regexp.GetError()) {
 result.AppendErrorWithFormat(
-"Function name regular expression could not be compiled: \"%s\"",
+"Function name regular expression could not be compiled: %s",
 llvm::toString(std::move(err)).c_str());
 result.SetStatus(eReturnStatusFailed);
 return false;


Index: lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py
===
--- /dev/null
+++ lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py
@@ -0,0 +1,14 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+def test_error(self):
+self.expect("breakpoint set --func-regex (", error=True,
+substrs=["error: Function name regular expression could " +
+ "not be compiled: parentheses not balanced"])
Index: lldb/source/Utility/RegularExpression.cpp
===
--- lldb/source/Utility/RegularExpression.cpp
+++ lldb/source/Utility/RegularExpression.cpp
@@ -35,7 +35,7 @@
 llvm::Error RegularExpression::GetError() const {
   std::string error;
   if (!m_regex.isValid(error))
-return llvm::make_error(llvm::inconvertibleErrorCode(),
-   error);
+return llvm::make_error(error,
+   llvm::inconvertibleErrorCode());
   return llvm::Error::success();
 }
Index: lldb/source/Commands/CommandObjectBreakpoint.cpp
===
--- lldb/source/Commands/CommandObjectBreakpoint.cpp
+++ lldb/source/Commands/CommandObjectBreakpoint.cpp
@@ -620,7 +620,7 @@
   RegularExpression regexp(m_options.m_func_regexp);
   if (llvm::Error err = regexp.GetError()) {
 result.AppendErrorWithFormat(
-"Function name regular expression could not be compiled: \"%s\"",
+"Function name regular expression could not be compiled: %s",
 llvm::toString(std::move(err)).c_str());
 result.SetStatus(eReturnStatusFailed);
 return false;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 84c398d - [lldb][TypeSystemClang] Desugar an elaborated type before checking if it's a typedef or getting a typedefed type

2020-04-27 Thread Aleksandr Urakov via lldb-commits


Author: Aleksandr Urakov
Date: 2020-04-27T11:08:19+03:00
New Revision: 84c398d375d9f3b0c2ce2a755dbaa57500e3f8ec

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

LOG: [lldb][TypeSystemClang] Desugar an elaborated type before checking if it's 
a typedef or getting a typedefed type

Summary:
Sometimes a result variable of some expression can be presented as an elaborated
type. In this case the methods `IsTypedefType()` and `GetTypedefedType()` of
`SBType` didn't work. This patch fixes that.

I didn't find the test for these API methods, so I added a basic test for this
too.

Reviewers: aprantl, teemperor, labath, leonid.mashinskiy

Reviewed By: teemperor

Subscribers: labath, lldb-commits

Tags: #lldb

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

Added: 
lldb/test/API/lang/cpp/typedef/Makefile
lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
lldb/test/API/lang/cpp/typedef/main.cpp

Modified: 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index 4f35d8ac51f0..7acdad2924fb 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -3541,7 +3541,8 @@ bool 
TypeSystemClang::IsScalarType(lldb::opaque_compiler_type_t type) {
 bool TypeSystemClang::IsTypedefType(lldb::opaque_compiler_type_t type) {
   if (!type)
 return false;
-  return GetQualType(type)->getTypeClass() == clang::Type::Typedef;
+  return RemoveWrappingTypes(GetQualType(type), {clang::Type::Typedef})
+ ->getTypeClass() == clang::Type::Typedef;
 }
 
 bool TypeSystemClang::IsVoidType(lldb::opaque_compiler_type_t type) {
@@ -4525,8 +4526,8 @@ CompilerType TypeSystemClang::CreateTypedef(
 CompilerType
 TypeSystemClang::GetTypedefedType(lldb::opaque_compiler_type_t type) {
   if (type) {
-const clang::TypedefType *typedef_type =
-llvm::dyn_cast(GetQualType(type));
+const clang::TypedefType *typedef_type = 
llvm::dyn_cast(
+RemoveWrappingTypes(GetQualType(type), {clang::Type::Typedef}));
 if (typedef_type)
   return GetType(typedef_type->getDecl()->getUnderlyingType());
   }

diff  --git a/lldb/test/API/lang/cpp/typedef/Makefile 
b/lldb/test/API/lang/cpp/typedef/Makefile
new file mode 100644
index ..3d0b98f13f3d
--- /dev/null
+++ b/lldb/test/API/lang/cpp/typedef/Makefile
@@ -0,0 +1,2 @@
+CXX_SOURCES := main.cpp
+include Makefile.rules

diff  --git a/lldb/test/API/lang/cpp/typedef/TestCppTypedef.py 
b/lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
new file mode 100644
index ..2aa2bcfe431a
--- /dev/null
+++ b/lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
@@ -0,0 +1,55 @@
+"""
+Test that we can retrieve typedefed types correctly
+"""
+
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import decorators
+
+class TestCppTypedef(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_typedef(self):
+"""
+Test that we retrieve typedefed types correctly
+"""
+
+# Build and run until the breakpoint
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.cpp")
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Set a breakpoint here", self.main_source_file)
+
+# Get the current frame
+frame = thread.GetSelectedFrame()
+
+# First of all, check that we can get a typedefed type correctly in a 
simple case
+
+expr_result = frame.EvaluateExpression("(SF)s")
+self.assertTrue(expr_result.IsValid(), "Expression failed with: " + 
str(expr_result.GetError()))
+
+typedef_type = expr_result.GetType();
+self.assertTrue(typedef_type.IsValid(), "Can't get `SF` type of 
evaluated expression")
+self.assertTrue(typedef_type.IsTypedefType(), "Type `SF` should be a 
typedef")
+
+typedefed_type = typedef_type.GetTypedefedType()
+self.assertTrue(typedefed_type.IsValid(), "Can't get `SF` typedefed 
type")
+self.assertEqual(typedefed_type.GetName(), "S", "Got invalid 
`SF` typedefed type")
+
+# Check that we can get a typedefed type correctly in the case
+# when an elaborated type is created during the parsing
+
+expr_result = frame.EvaluateExpression("(SF::V)s.value")
+self.assertTrue(expr_result.IsValid(), "Expression failed with: " + 
str(expr_result.GetError()))
+
+typedef_type = expr_result.GetType();
+self.assertTrue(typedef_type.IsValid(), "Can't get `SF::V` type of 
evaluated expression")
+self.asse

[Lldb-commits] [PATCH] D78697: [lldb][TypeSystemClang] Desugar an elaborated type before checking if it's a typedef or getting a typedefed type

2020-04-27 Thread Aleksandr Urakov via Phabricator via lldb-commits

aleksandr.urakov updated this revision to Diff 260235.
aleksandr.urakov added a comment.

Exactly! Removed unneeded wrapper.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78697

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/API/lang/cpp/typedef/Makefile
  lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
  lldb/test/API/lang/cpp/typedef/main.cpp

Index: lldb/test/API/lang/cpp/typedef/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/typedef/main.cpp
@@ -0,0 +1,13 @@
+template
+struct S {
+  typedef T V;
+
+  V value;
+};
+
+typedef S SF;
+
+int main (int argc, char const *argv[]) {
+  SF s{ .5 };
+  return 0; // Set a breakpoint here
+}
Index: lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
@@ -0,0 +1,55 @@
+"""
+Test that we can retrieve typedefed types correctly
+"""
+
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import decorators
+
+class TestCppTypedef(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_typedef(self):
+"""
+Test that we retrieve typedefed types correctly
+"""
+
+# Build and run until the breakpoint
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.cpp")
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Set a breakpoint here", self.main_source_file)
+
+# Get the current frame
+frame = thread.GetSelectedFrame()
+
+# First of all, check that we can get a typedefed type correctly in a simple case
+
+expr_result = frame.EvaluateExpression("(SF)s")
+self.assertTrue(expr_result.IsValid(), "Expression failed with: " + str(expr_result.GetError()))
+
+typedef_type = expr_result.GetType();
+self.assertTrue(typedef_type.IsValid(), "Can't get `SF` type of evaluated expression")
+self.assertTrue(typedef_type.IsTypedefType(), "Type `SF` should be a typedef")
+
+typedefed_type = typedef_type.GetTypedefedType()
+self.assertTrue(typedefed_type.IsValid(), "Can't get `SF` typedefed type")
+self.assertEqual(typedefed_type.GetName(), "S", "Got invalid `SF` typedefed type")
+
+# Check that we can get a typedefed type correctly in the case
+# when an elaborated type is created during the parsing
+
+expr_result = frame.EvaluateExpression("(SF::V)s.value")
+self.assertTrue(expr_result.IsValid(), "Expression failed with: " + str(expr_result.GetError()))
+
+typedef_type = expr_result.GetType();
+self.assertTrue(typedef_type.IsValid(), "Can't get `SF::V` type of evaluated expression")
+self.assertTrue(typedef_type.IsTypedefType(), "Type `SF::V` should be a typedef")
+
+typedefed_type = typedef_type.GetTypedefedType()
+self.assertTrue(typedefed_type.IsValid(), "Can't get `SF::V` typedefed type")
+self.assertEqual(typedefed_type.GetName(), "float", "Got invalid `SF::V` typedefed type")
Index: lldb/test/API/lang/cpp/typedef/Makefile
===
--- /dev/null
+++ lldb/test/API/lang/cpp/typedef/Makefile
@@ -0,0 +1,2 @@
+CXX_SOURCES := main.cpp
+include Makefile.rules
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -3541,7 +3541,8 @@
 bool TypeSystemClang::IsTypedefType(lldb::opaque_compiler_type_t type) {
   if (!type)
 return false;
-  return GetQualType(type)->getTypeClass() == clang::Type::Typedef;
+  return RemoveWrappingTypes(GetQualType(type), {clang::Type::Typedef})
+ ->getTypeClass() == clang::Type::Typedef;
 }
 
 bool TypeSystemClang::IsVoidType(lldb::opaque_compiler_type_t type) {
@@ -4525,8 +4526,8 @@
 CompilerType
 TypeSystemClang::GetTypedefedType(lldb::opaque_compiler_type_t type) {
   if (type) {
-const clang::TypedefType *typedef_type =
-llvm::dyn_cast(GetQualType(type));
+const clang::TypedefType *typedef_type = llvm::dyn_cast(
+RemoveWrappingTypes(GetQualType(type), {clang::Type::Typedef}));
 if (typedef_type)
   return GetType(typedef_type->getDecl()->getUnderlyingType());
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D78697: [lldb][TypeSystemClang] Desugar an elaborated type before checking if it's a typedef or getting a typedefed type

2020-04-27 Thread Aleksandr Urakov via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG84c398d375d9: [lldb][TypeSystemClang] Desugar an elaborated 
type before checking if it's a… (authored by aleksandr.urakov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78697

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/API/lang/cpp/typedef/Makefile
  lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
  lldb/test/API/lang/cpp/typedef/main.cpp

Index: lldb/test/API/lang/cpp/typedef/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/typedef/main.cpp
@@ -0,0 +1,13 @@
+template
+struct S {
+  typedef T V;
+
+  V value;
+};
+
+typedef S SF;
+
+int main (int argc, char const *argv[]) {
+  SF s{ .5 };
+  return 0; // Set a breakpoint here
+}
Index: lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/typedef/TestCppTypedef.py
@@ -0,0 +1,55 @@
+"""
+Test that we can retrieve typedefed types correctly
+"""
+
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import decorators
+
+class TestCppTypedef(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_typedef(self):
+"""
+Test that we retrieve typedefed types correctly
+"""
+
+# Build and run until the breakpoint
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.cpp")
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(
+self, "Set a breakpoint here", self.main_source_file)
+
+# Get the current frame
+frame = thread.GetSelectedFrame()
+
+# First of all, check that we can get a typedefed type correctly in a simple case
+
+expr_result = frame.EvaluateExpression("(SF)s")
+self.assertTrue(expr_result.IsValid(), "Expression failed with: " + str(expr_result.GetError()))
+
+typedef_type = expr_result.GetType();
+self.assertTrue(typedef_type.IsValid(), "Can't get `SF` type of evaluated expression")
+self.assertTrue(typedef_type.IsTypedefType(), "Type `SF` should be a typedef")
+
+typedefed_type = typedef_type.GetTypedefedType()
+self.assertTrue(typedefed_type.IsValid(), "Can't get `SF` typedefed type")
+self.assertEqual(typedefed_type.GetName(), "S", "Got invalid `SF` typedefed type")
+
+# Check that we can get a typedefed type correctly in the case
+# when an elaborated type is created during the parsing
+
+expr_result = frame.EvaluateExpression("(SF::V)s.value")
+self.assertTrue(expr_result.IsValid(), "Expression failed with: " + str(expr_result.GetError()))
+
+typedef_type = expr_result.GetType();
+self.assertTrue(typedef_type.IsValid(), "Can't get `SF::V` type of evaluated expression")
+self.assertTrue(typedef_type.IsTypedefType(), "Type `SF::V` should be a typedef")
+
+typedefed_type = typedef_type.GetTypedefedType()
+self.assertTrue(typedefed_type.IsValid(), "Can't get `SF::V` typedefed type")
+self.assertEqual(typedefed_type.GetName(), "float", "Got invalid `SF::V` typedefed type")
Index: lldb/test/API/lang/cpp/typedef/Makefile
===
--- /dev/null
+++ lldb/test/API/lang/cpp/typedef/Makefile
@@ -0,0 +1,2 @@
+CXX_SOURCES := main.cpp
+include Makefile.rules
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -3541,7 +3541,8 @@
 bool TypeSystemClang::IsTypedefType(lldb::opaque_compiler_type_t type) {
   if (!type)
 return false;
-  return GetQualType(type)->getTypeClass() == clang::Type::Typedef;
+  return RemoveWrappingTypes(GetQualType(type), {clang::Type::Typedef})
+ ->getTypeClass() == clang::Type::Typedef;
 }
 
 bool TypeSystemClang::IsVoidType(lldb::opaque_compiler_type_t type) {
@@ -4525,8 +4526,8 @@
 CompilerType
 TypeSystemClang::GetTypedefedType(lldb::opaque_compiler_type_t type) {
   if (type) {
-const clang::TypedefType *typedef_type =
-llvm::dyn_cast(GetQualType(type));
+const clang::TypedefType *typedef_type = llvm::dyn_cast(
+RemoveWrappingTypes(GetQualType(type), {clang::Type::Typedef}));
 if (typedef_type)
   return GetType(typedef_type->getDecl()->getUnderlyingType());
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D78882: [IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand().

2020-04-27 Thread Craig Topper via Phabricator via lldb-commits

craig.topper created this revision.
craig.topper added a reviewer: dblaikie.
Herald added subscribers: lldb-commits, cfe-commits, Kayjukh, frgossen, 
grosul1, dantrushin, Joonsoo, kerbowa, liufengdb, lucyrfox, mgester, 
arpith-jacob, csigg, nicolasvasilache, antiagainst, shauheen, jpienaar, 
rriddle, mehdi_amini, asbirlea, dexonsmith, steven_wu, george.burgess.iv, 
kbarton, aheejin, hiraditya, jgravelle-google, sbc100, nhaehnle, jvesely, 
nemanjai, dschuff, arsenm, jholewinski.
Herald added a reviewer: deadalnix.
Herald added a reviewer: ftynse.
Herald added projects: clang, LLDB, LLVM.

This method has been commented as deprecated for a while. Remove
it and replace all uses with the equivalent getCalledOperand().

I also made a few cleanups in here. For example, to removes use
of getElementType on a pointer when we could just use getFunctionType
from the call.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78882

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  lldb/source/Expression/IRInterpreter.cpp
  lldb/source/Plugins/ExpressionParser/Clang/IRDynamicChecks.cpp
  lldb/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
  llvm/include/llvm-c/Core.h
  llvm/include/llvm/CodeGen/FastISel.h
  llvm/include/llvm/IR/AbstractCallSite.h
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/Analysis/AliasAnalysisEvaluator.cpp
  llvm/lib/Analysis/InstructionSimplify.cpp
  llvm/lib/Analysis/Lint.cpp
  llvm/lib/Analysis/MemorySSA.cpp
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/Analysis/StackSafetyAnalysis.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
  llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
  llvm/lib/CodeGen/GlobalISel/InlineAsmLowering.cpp
  llvm/lib/CodeGen/PreISelIntrinsicLowering.cpp
  llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
  llvm/lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
  llvm/lib/CodeGen/WasmEHPrepare.cpp
  llvm/lib/CodeGen/WinEHPrepare.cpp
  llvm/lib/ExecutionEngine/Interpreter/Execution.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/IR/Core.cpp
  llvm/lib/IR/Instructions.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Target/AArch64/AArch64PromoteConstant.cpp
  llvm/lib/Target/AMDGPU/AMDGPUAnnotateKernelFeatures.cpp
  llvm/lib/Target/AMDGPU/AMDGPUFixFunctionBitcasts.cpp
  llvm/lib/Target/AMDGPU/AMDGPUTargetTransformInfo.cpp
  llvm/lib/Target/AMDGPU/SIISelLowering.cpp
  llvm/lib/Target/ARM/ARMFastISel.cpp
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp
  llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86WinEHState.cpp
  llvm/lib/Transforms/Coroutines/CoroSplit.cpp
  llvm/lib/Transforms/IPO/CalledValuePropagation.cpp
  llvm/lib/Transforms/IPO/GlobalOpt.cpp
  llvm/lib/Transforms/IPO/PruneEH.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
  llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/lib/Transforms/Instrumentation/ValueProfilePlugins.inc
  llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
  llvm/lib/Transforms/Utils/CallPromotionUtils.cpp
  llvm/lib/Transforms/Utils/Evaluator.cpp
  llvm/lib/Transforms/Utils/InlineFunction.cpp
  llvm/lib/Transforms/Utils/Local.cpp
  llvm/lib/Transforms/Utils/LowerInvoke.cpp
  llvm/lib/Transforms/Utils/SimplifyCFG.cpp
  llvm/test/LTO/X86/type-mapping-bug3.ll
  llvm/tools/llvm-diff/DiffConsumer.cpp
  llvm/tools/llvm-diff/DifferenceEngine.cpp
  mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp

Index: mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp
===
--- mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp
+++ mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp
@@ -720,7 +720,7 @@
   op = b.create(loc, tys, b.getSymbolRefAttr(callee->getName()),
 ops);
 } else {
-  Value calledValue = processValue(ci->getCalledValue());
+  Value calledValue = processValue(ci->getCalledOperand());
   if (!calledValue)
 return failure();
   ops.insert(ops.begin(), calledValue);
@@ -766,7 +766,7 @@
   ops, blocks[ii->getNormalDest()], normalArgs,
   blocks[ii->getUnwindDest()], unwindArgs);
 } else {
-  ops.i

[Lldb-commits] [PATCH] D78882: [IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand().

2020-04-27 Thread Alex Zinenko via Phabricator via lldb-commits

ftynse accepted this revision.
ftynse added a comment.
This revision is now accepted and ready to land.

LGTM for MLIR


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78882



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

[Lldb-commits] [PATCH] D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error.

2020-04-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added inline comments.



Comment at: lldb/source/API/SBDebugger.cpp:1205-1209
  options.ref());
 num_errors = interp.GetNumErrors();
 quit_requested = interp.GetQuitRequested();
 stopped_for_crash = interp.GetStoppedForCrash();
+stopped_for_error = interp.GetStoppedForError();

What's the relationship between `num_errors` and `stopped_for_error`? Could we 
infer that we stopped because of an error if `num_errors>0` ?


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D78825



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

[Lldb-commits] [PATCH] D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error.

2020-04-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D78825#2002598 , @vsk wrote:

> Can we delete an override of SBDebugger::RunCommandInterpreter, or are they 
> all part of the stable API?

They are. The way that has been handled so far is that once a function starts 
to get too many overloads, we create a overload taking a class like 
`SBFuncOptions`, which contains all the arguments and is extensible. That seems 
to have kind of happened here already, as we have the 
`SBCommandInterpreterRunOptions` class. However, in this case, that struct only 
contains "input" arguments, which is why I am reluctant to recommend shove 
output arguments there.

That said, I am wondering about the semantics of the `num_errors` argument. If 
it is nonzero only in cases where we "stop because of an error" (or we can 
adjust it so that this is the case), then maybe we don't need a new api for 
this...

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D78825

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

[Lldb-commits] [PATCH] D78462: get rid of PythonInteger::GetInteger()

2020-04-27 Thread Muhammad Omair Javaid via Phabricator via lldb-commits

omjavaid accepted this revision.
omjavaid added a comment.
This revision is now accepted and ready to land.

Thanks for getting this fixed.  Looks good now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78462



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

[Lldb-commits] [PATCH] D78396: [lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets

2020-04-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

That seems acceptable (though definitely not ideal), given that this is objc 
code, and probably no big endian machine will ever be running or debugging objc 
code...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78396



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

[Lldb-commits] [PATCH] D78839: [lldb-vscode] Add an option for loading core files

2020-04-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D78839#2004278 , @clayborg wrote:

> You might look around for a core file in another test location and be able to 
> use that.

Yep, there's plenty to choose from in 
`test/API/functionalities/postmortem/elf-core/`.

Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:533
   auto attachCommands = GetStrings(arguments, "attachCommands");
-  g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
+  auto core_file = GetString(arguments, "coreFile");
+  g_vsc.stop_at_entry =

I can't tell what does this return from this snippet. I don't think this is a 
good use of `auto`.

Comment at: lldb/tools/lldb-vscode/lldb-vscode.cpp:577
+else
+  g_vsc.target.LoadCore(core_file.data(), error);
 // Reenable async events

Judging by this, it probably returns a StringRef. Is it always guaranteed to be 
null-terminated?

Comment at: lldb/tools/lldb-vscode/package.json:226
+   "type": 
"string",
+   "description": 
"Path to the core file to debug. It's necessary to specify the \"program\" 
argument as well."
}

Is the second part really true? lldb is able to open a core file without 
specifying the main executable (and in some cases it will even automatically 
find the matching executable).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78839

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

[Lldb-commits] [PATCH] D78801: [LLDB] Add class ProcessWasm for WebAssembly debugging

2020-04-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D78801#2004248 , @clayborg wrote:

> So a few things here. It doesn't seem like it is necessary to create the 
> WasmProcessGDBRemote and IWasmProcess. It would be fine to extend the current 
> ProcessGDBRemote and ThreadGDBRemote classes. The whole reason seems to be 
> that the variables (globals, locals, etc) are fetched through the GDB server 
> API and that doesn't happen for other users of the protocol where this 
> information is fetched via the debug info. Is this correct? You seem to have 
> debug info and DWARF (since you mentioned a new DWARF expression opcode), so 
> how do variables actually work? Do you use debug info? What info for 
> variables do you need to fetch from the API?
>
> It also seems that you fetch the stack backtrace via the GBB remote protocol 
> as well. This would be easy to add in to the generic GDB remote protocol. 
> This could also be built in at the lldb_private::Process/lldb_private::Thread 
> API level where a process/thread specifies it fetches the variables and/or 
> stack itself instead of letting the unwind engine do its thing. This can be 
> really useful for instance if a core or minidump file that is able to store a 
> backtrace so that when you don't have all the system libraries you can still 
> get a good backtrace from a core file. So the backtrace part should 
> definitely be part of the core LLDB logic where it can ask a process or 
> thread if it provides a backtrace or not and we add new virtual APIs to the 
> lldb_private::Process/lldb_private::Thread classes to detect and handle this. 
> The ProcessGDBRemote and ThreadGDBRemote would then implement these functions 
> and answer "yes" if the GDB server supports fetching these things.
>
> So if you can elaborate in detail how variables work and how the stack trace 
> works and exactly what needs to go through the GDB server API, we can work 
> out how this should happen in LLDB. From what I understand right now I would:
>
> - modify lldb_private::Process/lldb_private::Thread to add new virtual (not 
> pure virtual) APIs that answer "false" when asked if the process/thread 
> provides variables and stacks


The above idea is fairly interesting, but I don't see why a new API like that 
would be necessary to implement it. We already have an abstraction for a 
producer of stack frames -- the `Unwind` class. Reusing the existing 
abstraction (as this patch does) seems like simpler/cleaner design then adding 
a new api, and then having users switch on its value.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78801



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

[Lldb-commits] [lldb] d00eaa0 - [lldb] Adjust TestExec code to be closer to real world code

2020-04-27 Thread Raphael Isemann via lldb-commits


Author: Raphael Isemann
Date: 2020-04-27T14:57:12+02:00
New Revision: d00eaa082b7cd6ada106ed01751abce65abd6dd8

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

LOG: [lldb] Adjust TestExec code to be closer to real world code

Summary:
For some reason the TestExec test on the macOS bots randomly fails with this 
error:
```
output: * thread #2, stop reason = EXC_BAD_ACCESS (code=1, address=0x108e66000)
  * frame #0: 0x000108e66000
[...]
  File 
"/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/functionalities/exec/TestExec.py",
 line 25, in test_hitting_exec
self.do_test(False)
  File 
"/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/functionalities/exec/TestExec.py",
 line 113, in do_test
"Stopped at breakpoint in exec'ed process.")
AssertionError: False is not True : Stopped at breakpoint in exec'ed process.
Config=x86_64-/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-11
```

I don't know why the test program is failing and I couldn't reproduce this 
problem on my own.
This patch is a stab in the dark that just tries to make the test code more 
similar to code which
we would expect in a user program to make whatever part of macOS happy that is 
currently
not liking our code.

The actual changes are:
* We pass in argv[0] that is describing otherprog path instead of the current 
argv[0].
* We pass in a non-null envp (which anyway doesn't seem to be allowed on macOS 
man page).

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: abidh, lldb-commits

Tags: #lldb

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

Added: 


Modified: 
lldb/test/API/functionalities/exec/main.cpp

Removed: 




diff  --git a/lldb/test/API/functionalities/exec/main.cpp 
b/lldb/test/API/functionalities/exec/main.cpp
index bec470fd13ef..51c67d5f232d 100644
--- a/lldb/test/API/functionalities/exec/main.cpp
+++ b/lldb/test/API/functionalities/exec/main.cpp
@@ -12,7 +12,8 @@ int main(int argc, char const **argv) {
   std::string directory_name(::dirname(buf));
 
   std::string other_program = directory_name + "/secondprog";
-  execve(other_program.c_str(), const_cast(argv), nullptr);
+  argv[0] = other_program.c_str();
+  execv(argv[0], const_cast(argv));
   perror("execve");
   abort();
 }



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

[Lldb-commits] [PATCH] D78801: [LLDB] Add class ProcessWasm for WebAssembly debugging

2020-04-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D78801#2004501 , @paolosev wrote:

> My initial idea was to keep all the Wasm-related code as much as possible 
> isolated in plugin classes.

While I would definitely like to see that happen, I don't think the current 
approach achieves that. The "IWasmProcess" is still in the wasm plugin so we 
still end up with a lot of "core" code depending on the wasm plugin. And if we 
put IWasmProcess into the "core", then it's not much different than putting the 
relevant APIs into the "Process" class directly (though it could introduce some 
grouping which might count for something). If we accept that 
DW_OP_WASM_location as a first-class entity, then having some core interfaces 
to support it would not seem unreasonable. The thing which makes that blurry is 
that this is a vendor extension, not an official "first class" thing.

> Now, I guess that the next steps instead would be to refactor the code to 
> eliminate the new classes WasmProcessGDBRemote and UnwindWasm and modify 
> existing ProcessGDBRemote and ThreadGDBRemote instead.

It may be interesting to see how that ends up looking like (maybe you could put 
that in a separate patch to compare), but I don't think that at this point we 
have chosen the right way to go forward, and we still need to discuss/think 
about things...

> PS, I am sorry for the late reply… this lockdown is making me a little 
> unproductive… :-(

You replied on the next business day. I don't think this is late by any 
standard.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78801

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

[Lldb-commits] [PATCH] D75241: [lldb] Adjust TestExec code to be closer to real world code

2020-04-27 Thread Raphael Isemann via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd00eaa082b7c: [lldb] Adjust TestExec code to be closer to 
real world code (authored by teemperor).

Changed prior to commit:
  https://reviews.llvm.org/D75241?vs=246911&id=260303#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75241

Files:
  lldb/test/API/functionalities/exec/main.cpp


Index: lldb/test/API/functionalities/exec/main.cpp
===
--- lldb/test/API/functionalities/exec/main.cpp
+++ lldb/test/API/functionalities/exec/main.cpp
@@ -12,7 +12,8 @@
   std::string directory_name(::dirname(buf));
 
   std::string other_program = directory_name + "/secondprog";
-  execve(other_program.c_str(), const_cast(argv), nullptr);
+  argv[0] = other_program.c_str();
+  execv(argv[0], const_cast(argv));
   perror("execve");
   abort();
 }


Index: lldb/test/API/functionalities/exec/main.cpp
===
--- lldb/test/API/functionalities/exec/main.cpp
+++ lldb/test/API/functionalities/exec/main.cpp
@@ -12,7 +12,8 @@
   std::string directory_name(::dirname(buf));
 
   std::string other_program = directory_name + "/secondprog";
-  execve(other_program.c_str(), const_cast(argv), nullptr);
+  argv[0] = other_program.c_str();
+  execv(argv[0], const_cast(argv));
   perror("execve");
   abort();
 }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] ff5264f - [lldb][cmake] Move the remove_module_flags call to the right place in debugserver's CMakeLists

2020-04-27 Thread Raphael Isemann via lldb-commits


Author: Raphael Isemann
Date: 2020-04-27T16:04:19+02:00
New Revision: ff5264f0c6f026b25e2d91d0f5d5377a156c1f40

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

LOG: [lldb][cmake] Move the remove_module_flags call to the right place in 
debugserver's CMakeLists

This code should always be executed, not just when building the debugserver
on its own. Fixes the modules build when building LLVM+LLDB together.

Added: 


Modified: 
lldb/tools/debugserver/CMakeLists.txt

Removed: 




diff  --git a/lldb/tools/debugserver/CMakeLists.txt 
b/lldb/tools/debugserver/CMakeLists.txt
index 8bd0ecc7d1ff..fc23cf3c7e20 100644
--- a/lldb/tools/debugserver/CMakeLists.txt
+++ b/lldb/tools/debugserver/CMakeLists.txt
@@ -13,13 +13,13 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
   include(debugserverConfig)
   include(AddLLDB)
 
-  # debugserver contains ObjC++ code, so let's disable Clang modules
-  # in this subdirectory to avoid building ObjC++ modules (which often
-  # doesn't properly work).
-  remove_module_flags()
-
   set(LLDB_SOURCE_DIR "${CMAKE_SOURCE_DIR}/../../")
   include_directories(${LLDB_SOURCE_DIR}/include)
 endif()
 
+# debugserver contains ObjC++ code, so let's disable Clang modules
+# in this subdirectory to avoid building ObjC++ modules (which often
+# doesn't properly work).
+remove_module_flags()
+
 add_subdirectory(source)



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

[Lldb-commits] [PATCH] D73206: Pass `CompileUnit *` along `DWARFDIE` for DWZ

2020-04-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

Yes, having main_unit come first seems reasonably hierarchical. I'm still 
unsure as to whether lldb_private::CompileUnit would not be better, but let's 
have a look at this first...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73206



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

[Lldb-commits] [PATCH] D77043: Fix process gdb-remote usage of value_regs/invalidate_regs

2020-04-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

Thanks for elaborating. Responses inline.

In D77043#1998621 , @omjavaid wrote:

> In D77043#1996983 , @labath wrote:
>
> > Where does the option which I proposed fit in? It sounds like it would be 
> > something like 1a), where we don't actually modify the "invalidate" numbers 
> > stored within lldb-server, but we just do the conversion at the protocol 
> > level. That way the "invalidate" numbers keep their meaning as "lldb" 
> > register numbers in lldb-server, just like they used to. They also keep 
> > referring to "lldb" register numbers on the client side, because the client 
> > puts the register "index" into the "lldb" field. The only inconsistency is 
> > that the "lldb" register numbers assigned to a specific register will be 
> > different on the client and server side. However:
> >
> > - this is not different from what happens in your patch, because you put 
> > the "server lldb" number into the "process plugin" field on the client
> > - it's not something we should actually rely on if we want to be able to 
> > communicate with non-matching server stubs
>
>
> As far as non-matching stubs are concerned lldb qRegisterInfo handler on host 
> only looks for eRegisterKindEHFrame, eRegisterKindGeneric, and 
> eRegisterKindDWARF. The remaining two fields of register kinds list i-e 
> eRegisterKindProcessPlugin and eRegisterKindLLDB are assigned same value of 
> index by host. It is interesting to note here that when LLDB goes on to 
> access any register on remote side by sending a 'g/G' or 'p/P' packets it 
> makes use of eRegisterKindProcessPlugin although both eRegisterKindLLDB and 
> eRegisterKindProcessPlugin are assigned the same value. So this patch 
> actually gives a remote stub or process plugin an option to send its own 
> regnum if it has to otherwise index will be used as the default behavior. I 
> think eRegisterKindProcessPlugin is there for this purpose in case a stub 
> wants to provide its own register number it can do so but we are actually not 
> allowing any provision of doing so in qRegisterInfo packet while this 
> provision is available in target xml packet and we use it while parsing 
> target xml.

I'm not convinced that this extra flexibility is needed for qRegisterInfo. I 
mean, there's already a register number  present in the `qRegisterInfo` query. 
If the stub can look up the appropriate register info when responding to 
`qRegisterInfoXY`, it should also be able to find the register when it receives 
a `p` packet. If the stub wants/needs to internally use different register 
numbers for any reason, it can remap the numbers internally any way it wants.

The situations gets trickier when it comes to `target.xml`. While we could 
assign register numbers sequentially (and this is what happens if `regnum` is 
not present), that could quickly get confusing, particularly if the xml 
description is spread over multiple files. That's why I think it makes sense to 
have such field in the target.xml. Another reason is that this field (unlike 
the `invalidate_regnums` or `ehframe_regnum` fields) is actually documented in 
the gdb spec for this packet.

>> It seems to me like this solution has the same downsides as the current 
>> patch, while having the upside of not requiring protocol changes. That means 
>> it can be revisited if we find it to be a problem, while a protocol change 
>> is more permanent. That's why I'd like to get a good understanding of why it 
>> won't work (or be ugly) if we're not going to do it, and so far I haven't 
>> gotten that.
> 
> options 1) is similar to what you have proposed whereby we update value_regs 
> and invalidate_regs nos to mean indices before first qRegisterinfo. What this 
> actually means is that register number of all concerned registers in register 
> info list will be updated (All SVE register will have an updated register 
> no). These registers numbers are also used by instruction emulation by 
> accessing the register infos array which for now does pose any problem for 
> now.

The question of instruction emulation is more interesting (and I'd really like 
to hear @jasonmolenda's take on all of this). I presume you mean the use of 
intstruction emulation on client side, right? (we shouldn't need instruction 
emulation in lldb-server on aarch64, and in any case, there it can use any 
register number it wishes).

I believe the only use of instruction emulation in the client right now is to 
compute the unwind plans. For that, you're right that the numbers of SVE 
registers don't matter much, as for this use case we are mostly interested in 
PC, SP, FP, etc., and those won't change. However, the dependence of that 
component on the "lldb" register numbers does make this approach smell. The 
question is what to do about that. One possibility is to make lldb-server (and 
all stubs which want to interact with lldb) send over the

[Lldb-commits] [lldb] 18e96a3 - [lldb/unittests] Skip IPv6 test on systems which don't have IPv6 configured

2020-04-27 Thread Pavel Labath via lldb-commits


Author: Pavel Labath
Date: 2020-04-27T17:33:20+02:00
New Revision: 18e96a31fe0214eb435e131e6ff585a899694576

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

LOG: [lldb/unittests] Skip IPv6 test on systems which don't have IPv6 configured

Sadly IPv6 is still not present anywhere. The test was attempting to
detect&skip such hosts, but the way it did that (essentially, by calling
getaddrinfo) meant that it only detected hosts which have IPv6 support
completely compiled out. It did not do anything about hosts which have
it compiled in, but lack runtime configuration even for the ::1 loopback
address.

This patch changes the detection logic to use a new method. It does it
by attempting to bind a socket to the appropriate loopback address. That
should ensure the hosts loopback interface is fully set up. In an effort
to avoid silently skipping the test on too many hosts, the test is
fairly strict about the kind of error it expects in these cases -- it
will only skip the test when receiving EADDRNOTAVAIL. If we find other
error codes that can be reasonably returned in these situations, we can
add more of them.

The (small) change in TCPSocket.cpp is to ensure that the code correctly
propagates the error received from the OS.

Added: 


Modified: 
lldb/source/Host/common/TCPSocket.cpp
lldb/unittests/Host/ConnectionFileDescriptorTest.cpp
lldb/unittests/Host/SocketTest.cpp
lldb/unittests/Host/SocketTestUtilities.cpp
lldb/unittests/Host/SocketTestUtilities.h

Removed: 




diff  --git a/lldb/source/Host/common/TCPSocket.cpp 
b/lldb/source/Host/common/TCPSocket.cpp
index 821574e8d822..76ae7f2bd01c 100644
--- a/lldb/source/Host/common/TCPSocket.cpp
+++ b/lldb/source/Host/common/TCPSocket.cpp
@@ -42,6 +42,16 @@ typedef const void *set_socket_option_arg_type;
 using namespace lldb;
 using namespace lldb_private;
 
+static Status GetLastSocketError() {
+  std::error_code EC;
+#ifdef _WIN32
+  EC = llvm::mapWindowsError(WSAGetLastError());
+#else
+  EC = std::error_code(errno, std::generic_category());
+#endif
+  return EC;
+}
+
 namespace {
 const int kType = SOCK_STREAM;
 }
@@ -192,10 +202,8 @@ Status TCPSocket::Listen(llvm::StringRef name, int 
backlog) {
   for (SocketAddress &address : addresses) {
 int fd = Socket::CreateSocket(address.GetFamily(), kType, IPPROTO_TCP,
   m_child_processes_inherit, error);
-if (error.Fail()) {
-  error.Clear();
+if (error.Fail())
   continue;
-}
 
 // enable local address reuse
 int option_value = 1;
@@ -216,6 +224,7 @@ Status TCPSocket::Listen(llvm::StringRef name, int backlog) 
{
   err = ::listen(fd, backlog);
 
 if (-1 == err) {
+  error = GetLastSocketError();
   CLOSE_SOCKET(fd);
   continue;
 }
@@ -228,9 +237,11 @@ Status TCPSocket::Listen(llvm::StringRef name, int 
backlog) {
 m_listen_sockets[fd] = address;
   }
 
-  if (m_listen_sockets.size() == 0)
-error.SetErrorString("Failed to connect port");
-  return error;
+  if (m_listen_sockets.size() == 0) {
+assert(error.Fail());
+return error;
+  }
+  return Status();
 }
 
 void TCPSocket::CloseListenSockets() {

diff  --git a/lldb/unittests/Host/ConnectionFileDescriptorTest.cpp 
b/lldb/unittests/Host/ConnectionFileDescriptorTest.cpp
index 655febc11d14..76c54a96b22e 100644
--- a/lldb/unittests/Host/ConnectionFileDescriptorTest.cpp
+++ b/lldb/unittests/Host/ConnectionFileDescriptorTest.cpp
@@ -22,11 +22,6 @@ class ConnectionFileDescriptorTest : public testing::Test {
   void TestGetURI(std::string ip) {
 std::unique_ptr socket_a_up;
 std::unique_ptr socket_b_up;
-if (!IsAddressFamilySupported(ip)) {
-  GTEST_LOG_(WARNING) << "Skipping test due to missing IPv"
-  << (IsIPv4(ip) ? "4" : "6") << " support.";
-  return;
-}
 CreateTCPConnectedSockets(ip, &socket_a_up, &socket_b_up);
 auto socket = socket_a_up.release();
 ConnectionFileDescriptor connection_file_descriptor(socket);
@@ -42,6 +37,14 @@ class ConnectionFileDescriptorTest : public testing::Test {
   }
 };
 
-TEST_F(ConnectionFileDescriptorTest, TCPGetURIv4) { TestGetURI("127.0.0.1"); }
-
-TEST_F(ConnectionFileDescriptorTest, TCPGetURIv6) { TestGetURI("::1"); }
+TEST_F(ConnectionFileDescriptorTest, TCPGetURIv4) {
+  if (!HostSupportsIPv4())
+return;
+  TestGetURI("127.0.0.1");
+}
+
+TEST_F(ConnectionFileDescriptorTest, TCPGetURIv6) {
+  if (!HostSupportsIPv6())
+return;
+  TestGetURI("::1");
+}

diff  --git a/lldb/unittests/Host/SocketTest.cpp 
b/lldb/unittests/Host/SocketTest.cpp
index 54548d36956c..c53d2660f0c8 100644
--- a/lldb/unittests/Host/SocketTest.cpp
+++ b/lldb/unittests/Host/SocketTest.cpp
@@ -111,10 +111,8 @@ TEST_F(SocketTest, TCPListen0ConnectAcc

[Lldb-commits] [PATCH] D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error.

2020-04-27 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere marked an inline comment as done.
JDevlieghere added inline comments.



Comment at: lldb/source/API/SBDebugger.cpp:1205-1209
  options.ref());
 num_errors = interp.GetNumErrors();
 quit_requested = interp.GetQuitRequested();
 stopped_for_crash = interp.GetStoppedForCrash();
+stopped_for_error = interp.GetStoppedForError();

labath wrote:
> What's the relationship between `num_errors` and `stopped_for_error`? Could 
> we infer that we stopped because of an error if `num_errors>0` ?
I considered that, `m_num_errors` is incremented unconditionally, while 
stopped_for_error is only set when `eHandleCommandFlagStopOnError` is set. If 
you know that "stop on error" is set you could infer it based on the value 
being non-zero, but to me that sounds a bit fragile, and given that we already 
have `stopped_for_crash` I preferred the symmetry. I'm not married to this 
approach so if you feel strongly about it I'm happy to change it. 


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D78825



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

[Lldb-commits] [lldb] 58435f6 - [lldb] Fix windows build break from 18e96a31

2020-04-27 Thread Pavel Labath via lldb-commits


Author: Pavel Labath
Date: 2020-04-27T19:22:44+02:00
New Revision: 58435f69cb0db54e7a76d47101bbc5e74cb5c31c

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

LOG: [lldb] Fix windows build break from 18e96a31

Added: 


Modified: 
lldb/source/Host/common/TCPSocket.cpp

Removed: 




diff  --git a/lldb/source/Host/common/TCPSocket.cpp 
b/lldb/source/Host/common/TCPSocket.cpp
index 76ae7f2bd01c..d6f6b2cd30a7 100644
--- a/lldb/source/Host/common/TCPSocket.cpp
+++ b/lldb/source/Host/common/TCPSocket.cpp
@@ -18,6 +18,7 @@
 
 #include "llvm/Config/llvm-config.h"
 #include "llvm/Support/Errno.h"
+#include "llvm/Support/WindowsError.h"
 #include "llvm/Support/raw_ostream.h"
 
 #if LLDB_ENABLE_POSIX



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

[Lldb-commits] [lldb] 8f5beb4 - [lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets.

2020-04-27 Thread Med Ismail Bennani via lldb-commits


Author: Med Ismail Bennani
Date: 2020-04-27T22:10:11+02:00
New Revision: 8f5beb4c4b114f2cd827b10b5358f0d79d8bb691

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

LOG: [lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets.

This patch improves data formatting for CoreFoundation containers:
CFDictionary and CFSet.

These data formatters make the containers and their children appear in Xcode's
variables view (and on the command line) without having to expand the
data structure.

Previous implementation only supported showing the container's element count.

```
(lldb) frame var dict
(__NSCFDictionary *) dict = 0x0001004062b0 2 key/value pairs

(lldb) frame var set
(__NSCFSet *) set = 0x000100406330 2 elements
```
Now the variable can be dereferenced to dispaly the container's children:

```
(lldb) frame var *dict
(__NSCFDictionary) *dict = {
  [0] = {
key = 0x00014050 @"123"
value = 0x00014090 @"456"
  }
  [1] = {
key = 0x00014030 @"abc"
value = 0x00014070 @"def"
  }
}

(lldb) frame var *set
(__NSCFSet) *set = {
  [0] = 0x00014050 @"123"
  [1] = 0x00014030 @"abc"
}
```

rdar://39882287

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

Signed-off-by: Med Ismail Bennani 

Added: 
lldb/source/Plugins/Language/ObjC/CFBasicHash.cpp
lldb/source/Plugins/Language/ObjC/CFBasicHash.h

Modified: 
lldb/source/Plugins/Language/ObjC/CMakeLists.txt
lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
lldb/source/Plugins/Language/ObjC/NSDictionary.h
lldb/source/Plugins/Language/ObjC/NSSet.cpp
lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m

Removed: 




diff  --git a/lldb/source/Plugins/Language/ObjC/CFBasicHash.cpp 
b/lldb/source/Plugins/Language/ObjC/CFBasicHash.cpp
new file mode 100644
index ..42cda0146f2e
--- /dev/null
+++ b/lldb/source/Plugins/Language/ObjC/CFBasicHash.cpp
@@ -0,0 +1,114 @@
+#include "CFBasicHash.h"
+
+#include "lldb/Utility/Endian.h"
+
+using namespace lldb;
+using namespace lldb_private;
+
+bool CFBasicHash::IsValid() const {
+  if (m_address != LLDB_INVALID_ADDRESS) {
+if (m_ptr_size == 4 && m_ht_32)
+  return true;
+else if (m_ptr_size == 8 && m_ht_64)
+  return true;
+else
+  return false;
+  }
+  return false;
+}
+
+bool CFBasicHash::Update(addr_t addr, ExecutionContextRef exe_ctx_rf) {
+  if (addr == LLDB_INVALID_ADDRESS || !addr)
+return false;
+
+  m_address = addr;
+  m_exe_ctx_ref = exe_ctx_rf;
+  m_ptr_size =
+  m_exe_ctx_ref.GetTargetSP()->GetArchitecture().GetAddressByteSize();
+  m_byte_order = m_exe_ctx_ref.GetTargetSP()->GetArchitecture().GetByteOrder();
+
+  if (m_ptr_size == 4)
+return UpdateFor(m_ht_32);
+  else if (m_ptr_size == 8)
+return UpdateFor(m_ht_64);
+  return false;
+
+  llvm_unreachable(
+  "Unsupported architecture. Only 32bits and 64bits supported.");
+}
+
+template 
+bool CFBasicHash::UpdateFor(std::unique_ptr<__CFBasicHash> &m_ht) {
+  if (m_byte_order != endian::InlHostByteOrder())
+return false;
+  
+  Status error;
+  Target *target = m_exe_ctx_ref.GetTargetSP().get();
+  addr_t addr = m_address.GetLoadAddress(target);
+  size_t size = sizeof(typename __CFBasicHash::RuntimeBase) +
+sizeof(typename __CFBasicHash::Bits);
+
+  m_ht = std::make_unique<__CFBasicHash>();
+  m_exe_ctx_ref.GetProcessSP()->ReadMemory(addr, m_ht.get(),
+   size, error);
+  if (error.Fail())
+return false;
+
+  m_mutable = !(m_ht->base.cfinfoa & (1 << 6));
+  m_multi = m_ht->bits.counts_offset;
+  m_type = static_cast(m_ht->bits.keys_offset);
+  addr_t ptr_offset = addr + size;
+  size_t ptr_count = GetPointerCount();
+  size = ptr_count * sizeof(T);
+
+  m_exe_ctx_ref.GetProcessSP()->ReadMemory(ptr_offset, m_ht->pointers, size,
+   error);
+
+  if (error.Fail()) {
+m_ht = nullptr;
+return false;
+  }
+
+  return true;
+}
+
+size_t CFBasicHash::GetCount() const {
+  if (!IsValid())
+return 0;
+
+  if (!m_multi)
+return (m_ptr_size == 4) ? m_ht_32->bits.used_buckets
+ : m_ht_64->bits.used_buckets;
+
+  //  FIXME: Add support for multi
+  return 0;
+}
+
+size_t CFBasicHash::GetPointerCount() const {
+  if (!IsValid())
+return 0;
+
+  if (m_multi)
+return 3; // Bits::counts_offset;
+  return (m_type == HashType::dict) + 1;
+}
+
+addr_t CFBasicHash::GetKeyPointer() const {
+  if (!IsValid())
+return LLDB_INVALID_ADDRESS;
+
+  if (m_ptr_size == 4)
+return

[Lldb-commits] [PATCH] D78396: [lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets

2020-04-27 Thread Med Ismail Bennani via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8f5beb4c4b11: [lldb/Dataformatter] Add support for 
CoreFoundation Dictionaries and Sets. (authored by mib).

Changed prior to commit:
  https://reviews.llvm.org/D78396?vs=260012&id=260447#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78396

Files:
  lldb/source/Plugins/Language/ObjC/CFBasicHash.cpp
  lldb/source/Plugins/Language/ObjC/CFBasicHash.h
  lldb/source/Plugins/Language/ObjC/CMakeLists.txt
  lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
  lldb/source/Plugins/Language/ObjC/NSDictionary.h
  lldb/source/Plugins/Language/ObjC/NSSet.cpp
  lldb/source/Plugins/Language/ObjC/ObjCLanguage.cpp
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
  lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m

Index: lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
+++ lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
@@ -376,13 +376,19 @@
 	[newMutableDictionary setObject:@"foo" forKey:@"bar19"];
 	[newMutableDictionary setObject:@"foo" forKey:@"bar20"];
 
-	id cfKeys[2] = { @"foo", @"bar", @"baz", @"quux" };
-	id cfValues[2] = { @"foo", @"bar", @"baz", @"quux" };
-	NSDictionary *nsDictionary = CFBridgingRelease(CFDictionaryCreate(nil, (void *)cfKeys, (void *)cfValues, 2, nil, nil));
-	CFDictionaryRef cfDictionaryRef = CFDictionaryCreate(nil, (void *)cfKeys, (void *)cfValues, 3, nil, nil);
-
-	NSAttributedString* attrString = [[NSAttributedString alloc] initWithString:@"hello world from foo" attributes:newDictionary];
-	[attrString isEqual:nil];
+id cfKeys[4] = {@"foo", @"bar", @"baz", @"quux"};
+id cfValues[4] = {@"foo", @"bar", @"baz", @"quux"};
+NSDictionary *nsDictionary = CFBridgingRelease(CFDictionaryCreate(
+nil, (void *)cfKeys, (void *)cfValues, 2, nil, nil));
+NSDictionary *nscfDictionary = CFBridgingRelease(CFDictionaryCreate(
+nil, (void *)cfKeys, (void *)cfValues, 4, nil, nil));
+CFDictionaryRef cfDictionaryRef = CFDictionaryCreate(
+nil, (void *)cfKeys, (void *)cfValues, 3, nil, nil);
+
+NSAttributedString *attrString = [[NSAttributedString alloc]
+initWithString:@"hello world from foo"
+attributes:newDictionary];
+[attrString isEqual:nil];
 	NSAttributedString* mutableAttrString = [[NSMutableAttributedString alloc] initWithString:@"hello world from foo" attributes:newDictionary];
 	[mutableAttrString isEqual:nil];
 
@@ -411,9 +417,11 @@
 
 	NSSet* nsset = [[NSSet alloc] initWithObjects:str1,str2,str3,nil];
 	NSSet *nsmutableset = [[NSMutableSet alloc] initWithObjects:str1,str2,str3,nil];
-	[nsmutableset addObject:str4];
+[nsmutableset addObject:str4];
+NSSet *nscfSet =
+CFBridgingRelease(CFSetCreate(nil, (void *)cfValues, 2, nil));
 
-	CFDataRef data_ref = CFDataCreate(kCFAllocatorDefault, [immutableData bytes], 5);
+CFDataRef data_ref = CFDataCreate(kCFAllocatorDefault, [immutableData bytes], 5);
 
 	CFMutableDataRef mutable_data_ref = CFDataCreateMutable(kCFAllocatorDefault, 8);
 	CFDataAppendBytes(mutable_data_ref, [mutableData bytes], 5);
Index: lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
@@ -29,6 +29,8 @@
 ' 2 key/value pairs',
 '(NSDictionary *) newDictionary = ',
 ' 12 key/value pairs',
+'(NSDictionary *) nscfDictionary = ',
+' 4 key/value pairs',
 '(CFDictionaryRef) cfDictionaryRef = ',
 ' 3 key/value pairs',
 '(NSDictionary *) newMutableDictionary = ',
@@ -40,6 +42,36 @@
 ])
 
 self.expect(
+'frame variable -d run-target *nscfDictionary',
+patterns=[
+'\(__NSCFDictionary\) \*nscfDictionary =',
+'key = 0x.* @"foo"',
+'value = 0x.* @"foo"',
+'key = 0x.* @"bar"',
+'value = 0x.* @"bar"',
+'key = 0x.* @"baz"',
+'value = 0x.* @"baz"',
+'key = 0x.* @"quux"',
+'value = 0x.* @"quux"',
+])
+
+
+self.expect(
+  'frame

[Lldb-commits] [lldb] 4d40d66 - Fix up a clang-tidy nit about using empty rather than size == 0.

2020-04-27 Thread Eric Christopher via lldb-commits


Author: Eric Christopher
Date: 2020-04-27T15:22:44-07:00
New Revision: 4d40d6640238a8d304c39603a4938de85301fcba

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

LOG: Fix up a clang-tidy nit about using empty rather than size == 0.

Added: 


Modified: 
lldb/source/Host/common/TCPSocket.cpp

Removed: 




diff  --git a/lldb/source/Host/common/TCPSocket.cpp 
b/lldb/source/Host/common/TCPSocket.cpp
index d6f6b2cd30a7..047cb0e4c2bf 100644
--- a/lldb/source/Host/common/TCPSocket.cpp
+++ b/lldb/source/Host/common/TCPSocket.cpp
@@ -238,7 +238,7 @@ Status TCPSocket::Listen(llvm::StringRef name, int backlog) 
{
 m_listen_sockets[fd] = address;
   }
 
-  if (m_listen_sockets.size() == 0) {
+  if (m_listen_sockets.empty()) {
 assert(error.Fail());
 return error;
   }



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

[Lldb-commits] [PATCH] D78839: [lldb-vscode] Add an option for loading core files

2020-04-27 Thread walter erquinigo via Phabricator via lldb-commits

wallace updated this revision to Diff 260501.
wallace added a comment.

Added a test, which was easier than I thought!
I tested it on mac as well, so I hope it'll work well on the buildbots.

I also removed that bad use of auto. It seems that all StringRefs gotten from 
the JSON object are null-terminated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78839

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
  lldb/test/API/tools/lldb-vscode/coreFile/TestVSCode_coreFile.py
  lldb/test/API/tools/lldb-vscode/coreFile/linux-x86_64.core
  lldb/test/API/tools/lldb-vscode/coreFile/linux-x86_64.out
  lldb/tools/lldb-vscode/README.md
  lldb/tools/lldb-vscode/lldb-vscode.cpp
  lldb/tools/lldb-vscode/package.json

Index: lldb/tools/lldb-vscode/package.json
===
--- lldb/tools/lldb-vscode/package.json
+++ lldb/tools/lldb-vscode/package.json
@@ -218,8 +218,12 @@
 			},
 			"exitCommands": {
 "type": "array",
-	"description": "Commands executed at the end of debugging session.",
-	"default": []
+"description": "Commands executed at the end of debugging session.",
+"default": []
+			},
+			"coreFile": {
+"type": "string",
+"description": "Path to the core file to debug."
 			}
 		}
 	}
Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -530,7 +530,9 @@
   g_vsc.stop_commands = GetStrings(arguments, "stopCommands");
   g_vsc.exit_commands = GetStrings(arguments, "exitCommands");
   auto attachCommands = GetStrings(arguments, "attachCommands");
-  g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
+  llvm::StringRef core_file = GetString(arguments, "coreFile");
+  g_vsc.stop_at_entry =
+  core_file.empty() ? GetBoolean(arguments, "stopOnEntry", false) : true;
   const auto debuggerRoot = GetString(arguments, "debuggerRoot");
 
   // This is a hack for loading DWARF in .o files on Mac where the .o files
@@ -569,7 +571,10 @@
 // Disable async events so the attach will be successful when we return from
 // the launch call and the launch will happen synchronously
 g_vsc.debugger.SetAsync(false);
-g_vsc.target.Attach(attach_info, error);
+if (core_file.empty())
+  g_vsc.target.Attach(attach_info, error);
+else
+  g_vsc.target.LoadCore(core_file.data(), error);
 // Reenable async events
 g_vsc.debugger.SetAsync(true);
   } else {
@@ -584,7 +589,7 @@
 
   SetSourceMapFromArguments(*arguments);
 
-  if (error.Success()) {
+  if (error.Success() && core_file.empty()) {
 auto attached_pid = g_vsc.target.GetProcess().GetProcessID();
 if (attached_pid == LLDB_INVALID_PROCESS_ID) {
   if (attachCommands.empty())
Index: lldb/tools/lldb-vscode/README.md
===
--- lldb/tools/lldb-vscode/README.md
+++ lldb/tools/lldb-vscode/README.md
@@ -181,15 +181,15 @@
 
 ### Loading a Core File
 
-Loading a core file can use the `"attach"` request along with the
-`"attachCommands"` to implement a custom attach:
+This loads the coredump file `/cores/123.core` associated with the program
+`/tmp/a.out`:
 
 ```javascript
 {
-  "name": "Attach to Name (wait)",
+  "name": "Load coredump",
   "type": "lldb-vscode",
   "request": "attach",
-  "attachCommands": ["target create -c /path/to/123.core /path/to/executable"],
-  "stopOnEntry": false
+  "coreFile": "/cores/123.core",
+  "program": "/tmp/a.out"
 }
 ```
Index: lldb/test/API/tools/lldb-vscode/coreFile/TestVSCode_coreFile.py
===
--- /dev/null
+++ lldb/test/API/tools/lldb-vscode/coreFile/TestVSCode_coreFile.py
@@ -0,0 +1,36 @@
+"""
+Test lldb-vscode coreFile attaching
+"""
+
+
+import unittest2
+import vscode
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+import lldbvscode_testcase
+import os
+
+
+class TestVSCode_coreFile(lldbvscode_testcase.VSCodeTestCaseBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipIfWindows
+@skipIfRemote
+@skipIfLLVMTargetMissing("X86")
+def test_core_file(self):
+current_dir = os.path.dirname(os.path.realpath(__file__))
+exe_file = os.path.join(current_dir, "linux-x86_64.out")
+core_file = os.path.join(current_dir, "linux-x86_64.core")
+
+self.create_debug_adaptor()
+self.attach(exe_file, coreFile=core_file)
+
+frames = self.get_stackFrames()
+self.assertEquals(
+frames,
+[{'column': 0, 'id': 524288, 'line': 4, 'name': 'bar', 'sou

[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

2020-04-27 Thread Jim Ingham via Phabricator via lldb-commits

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

The way both the REPL and the --top-level mode of the expression parser work is 
that they compile and JIT the code the user provided, and then look through the 
resultant IR and find any llvm::Functions produced by the compilation.  Then it 
iterates over those functions and if they are marked "external", it adds them 
to a table of functions that it then makes available to subsequent expressions.

The test we were using for "is external" was hasExternalLinkage || 
hasLinkOnceODRLinkage.  However, there's a third form of external function: 
hasWeakODRLinkage that can sometimes be produced, which is also intended to be 
an exported symbol.  This  patch just includes that predicate to the test we 
were doing.

I don't have a way to write a C-based test for this as I don't know how to 
craft a user expression in C that will make such a thing.  I asked around a bit 
and nobody had an easy way to do this.

OTOH, the swift compiler uses this linkage type when it makes the "default 
argument provider" for a function with default arguments.  So I can easily 
write a swift REPL test for this.  But if somebody knows how to make a C 
function in the lldb expression parser with a WeakODRLinkage, show me and I'll 
happily add a test for it here.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78972

Files:
  lldb/source/Expression/IRExecutionUnit.cpp


Index: lldb/source/Expression/IRExecutionUnit.cpp
===
--- lldb/source/Expression/IRExecutionUnit.cpp
+++ lldb/source/Expression/IRExecutionUnit.cpp
@@ -331,7 +331,8 @@
   continue;
 
 const bool external =
-function.hasExternalLinkage() || function.hasLinkOnceODRLinkage();
+function.hasExternalLinkage() || function.hasLinkOnceODRLinkage()
+|| function.hasWeakODRLinkage();
 
 void *fun_ptr = m_execution_engine_up->getPointerToFunction(&function);
 


Index: lldb/source/Expression/IRExecutionUnit.cpp
===
--- lldb/source/Expression/IRExecutionUnit.cpp
+++ lldb/source/Expression/IRExecutionUnit.cpp
@@ -331,7 +331,8 @@
   continue;
 
 const bool external =
-function.hasExternalLinkage() || function.hasLinkOnceODRLinkage();
+function.hasExternalLinkage() || function.hasLinkOnceODRLinkage()
+|| function.hasWeakODRLinkage();
 
 void *fun_ptr = m_execution_engine_up->getPointerToFunction(&function);
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D78978: [LLDB] Add support for WebAssembly debugging

2020-04-27 Thread Paolo Severini via Phabricator via lldb-commits

paolosev created this revision.
paolosev added reviewers: labath, clayborg.
paolosev added a project: LLDB.
Herald added subscribers: lldb-commits, sunfish, aheejin, jgravelle-google, 
sbc100, aprantl, mgorny, dschuff.
paolosev edited the summary of this revision.

This patch is a refactoring of  https://reviews.llvm.org/D78801. As suggested, 
I have created a separate patch to more easily compare the implementations.
Even here, the goal is to use the GDB-remote protocol to connect to a Wasm 
engine that implements a GDB-remote stub that offers the ability to access the 
engine runtime internal state.

Here I am removing the interface IWasmProcess and the new class 
WasmProcessGDBRemote and moving most of the Wasm logic in `ProcessGDBRemote`.
I am still adding the new Unwind class `UnwindWasm`, which now however is in 
core and not in plugins code.  Having a Unwind-derived class for Wasm unwinding 
seems to be the cleanest solution.

The advantage with this new design is that the required changes are smaller and 
isolated in a few places.
The drawback is that three 'core' classes (UnwindWasm, Value and 
DWARFExpression) have now a dependency on ProcessGDBRemote and/or 
ThreadGDBRemote. This could be avoided re-introducing a core interface like 
IWasmProcess. We could add a couple of virtual method  `bool IsWasmProcess()` 
and `IWasmProcess* AsWasmProcess()` to Process, which would be overridden by 
ProcessGDBRemote. Then these classes could just query this interface, removing 
direct dependencies on GDBRemote.

I am also adding a new `qSupported` flag named "wasm" that should tell LLDB 
whether the remote supports Wasm debugging.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78978

Files:
  lldb/include/lldb/Target/UnwindWasm.h
  lldb/source/Core/Value.cpp
  lldb/source/Expression/DWARFExpression.cpp
  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/CMakeLists.txt
  lldb/source/Target/Thread.cpp
  lldb/source/Target/UnwindWasm.cpp

Index: lldb/source/Target/UnwindWasm.cpp
===
--- /dev/null
+++ lldb/source/Target/UnwindWasm.cpp
@@ -0,0 +1,75 @@
+//===-- UnwindWasm.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 "lldb/Target/UnwindWasm.h"
+#include "lldb/Target/Thread.h"
+
+#include "Plugins/Process/gdb-remote/ProcessGDBRemote.h"
+#include "Plugins/Process/gdb-remote/ThreadGDBRemote.h"
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace process_gdb_remote;
+
+class WasmGDBRemoteRegisterContext : public GDBRemoteRegisterContext {
+public:
+  WasmGDBRemoteRegisterContext(ThreadGDBRemote &thread,
+   uint32_t concrete_frame_idx,
+   GDBRemoteDynamicRegisterInfo ®_info,
+   uint64_t pc)
+  : GDBRemoteRegisterContext(thread, concrete_frame_idx, reg_info, false,
+ false) {
+PrivateSetRegisterValue(0, pc);
+  }
+};
+
+lldb::RegisterContextSP
+UnwindWasm::DoCreateRegisterContextForFrame(lldb_private::StackFrame *frame) {
+  if (m_frames.size() <= frame->GetFrameIndex()) {
+return lldb::RegisterContextSP();
+  }
+
+  ThreadSP thread = frame->GetThread();
+  ThreadGDBRemote *gdb_thread = static_cast(thread.get());
+  ProcessGDBRemote *gdb_process =
+  static_cast(thread->GetProcess().get());
+  std::shared_ptr reg_ctx_sp =
+  std::make_shared(
+  *gdb_thread, frame->GetConcreteFrameIndex(),
+  gdb_process->m_register_info, m_frames[frame->GetFrameIndex()]);
+  return reg_ctx_sp;
+}
+
+uint32_t UnwindWasm::DoGetFrameCount() {
+  if (!m_unwind_complete) {
+m_unwind_complete = true;
+m_frames.clear();
+
+ProcessGDBRemote *gdb_process =
+static_cast(GetThread().GetProcess().get());
+if (!gdb_process->GetWasmCallStack(m_frames))
+  return 0;
+  }
+  return m_frames.size();
+}
+
+bool UnwindWasm::DoGetFrameInfoAtIndex(uint32_t frame_idx, lldb::addr_t &cfa,
+   lldb::addr_t &pc,
+   bool &behaves_like_zeroth_frame) {
+  if (m_frames.size() == 0) {
+DoGetFrameCount();
+  }
+
+  if (frame_idx < m_frames.size()) {
+behaves_like_zeroth_frame = (frame_idx == 0);
+cfa = 0;
+pc = m_frames[frame_idx];
+return true;
+  }
+  return false;
+}
\ No newline at end of file
Index: lldb/source/Target/Thread.cpp
==

[Lldb-commits] [PATCH] D78801: [LLDB] Add class ProcessWasm for WebAssembly debugging

2020-04-27 Thread Paolo Severini via Phabricator via lldb-commits

paolosev added a comment.

Thanks for your comments!
I have refactored this code in a separate patch, 
https://reviews.llvm.org/D78978, removing WasmProcessGDBRemote, moving part of 
the logic into ProcessGDBRemote but still keeping class UnwindWasm.
Let me know what you think...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78801



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

[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

2020-04-27 Thread Davide Italiano via Phabricator via lldb-commits

davide added a comment.

Weak functions can actually be overridden -- I'm really wondering whether this 
causes issues here. Do you have an example [even if it's in swift] of a symbol 
that's not exported correctly?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78972



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

[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

2020-04-27 Thread Davide Italiano via Phabricator via lldb-commits

davide added a comment.

Saleem is the right person to review this change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78972



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

[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

2020-04-27 Thread Davide Italiano via Phabricator via lldb-commits

davide added a comment.

I'm really worried about this change -- and we should think about it very 
carefully because it might cause the LLVM verifier to freak out -- or even 
worse, causing random crashes when executing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78972



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

[Lldb-commits] [PATCH] D75607: [lldb] Use llvm::MC for register numbers in AArch64 ABIs

2020-04-27 Thread Muhammad Omair Javaid via Phabricator via lldb-commits

omjavaid accepted this revision.
omjavaid added a comment.
This revision is now accepted and ready to land.

Looks good to me. Tested on AArch64/Linux with no regressions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75607



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

[Lldb-commits] [lldb] a58b62b - [IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand().

2020-04-27 Thread Craig Topper via lldb-commits


Author: Craig Topper
Date: 2020-04-27T22:17:03-07:00
New Revision: a58b62b4a2b96c31b49338b262b609db746449e8

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

LOG: [IR] Replace all uses of CallBase::getCalledValue() with 
getCalledOperand().

This method has been commented as deprecated for a while. Remove
it and replace all uses with the equivalent getCalledOperand().

I also made a few cleanups in here. For example, to removes use
of getElementType on a pointer when we could just use getFunctionType
from the call.

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGObjC.cpp
clang/lib/CodeGen/CodeGenFunction.cpp
lldb/source/Expression/IRInterpreter.cpp
lldb/source/Plugins/ExpressionParser/Clang/IRDynamicChecks.cpp
lldb/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
llvm/include/llvm-c/Core.h
llvm/include/llvm/CodeGen/FastISel.h
llvm/include/llvm/IR/AbstractCallSite.h
llvm/include/llvm/IR/InstrTypes.h
llvm/lib/Analysis/AliasAnalysisEvaluator.cpp
llvm/lib/Analysis/InstructionSimplify.cpp
llvm/lib/Analysis/Lint.cpp
llvm/lib/Analysis/MemorySSA.cpp
llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
llvm/lib/Analysis/StackSafetyAnalysis.cpp
llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
llvm/lib/CodeGen/CodeGenPrepare.cpp
llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
llvm/lib/CodeGen/GlobalISel/InlineAsmLowering.cpp
llvm/lib/CodeGen/PreISelIntrinsicLowering.cpp
llvm/lib/CodeGen/SelectionDAG/FastISel.cpp
llvm/lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
llvm/lib/CodeGen/WasmEHPrepare.cpp
llvm/lib/CodeGen/WinEHPrepare.cpp
llvm/lib/ExecutionEngine/Interpreter/Execution.cpp
llvm/lib/IR/AsmWriter.cpp
llvm/lib/IR/Core.cpp
llvm/lib/IR/Instructions.cpp
llvm/lib/IR/Verifier.cpp
llvm/lib/Target/AArch64/AArch64PromoteConstant.cpp
llvm/lib/Target/AMDGPU/AMDGPUAnnotateKernelFeatures.cpp
llvm/lib/Target/AMDGPU/AMDGPUFixFunctionBitcasts.cpp
llvm/lib/Target/AMDGPU/AMDGPUTargetTransformInfo.cpp
llvm/lib/Target/AMDGPU/SIISelLowering.cpp
llvm/lib/Target/ARM/ARMFastISel.cpp
llvm/lib/Target/ARM/ARMISelLowering.cpp
llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp
llvm/lib/Target/NVPTX/NVPTXISelLowering.cpp
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
llvm/lib/Target/WebAssembly/WebAssemblyFixFunctionBitcasts.cpp
llvm/lib/Target/WebAssembly/WebAssemblyLowerEmscriptenEHSjLj.cpp
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/lib/Target/X86/X86WinEHState.cpp
llvm/lib/Transforms/Coroutines/CoroSplit.cpp
llvm/lib/Transforms/IPO/CalledValuePropagation.cpp
llvm/lib/Transforms/IPO/GlobalOpt.cpp
llvm/lib/Transforms/IPO/PruneEH.cpp
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
llvm/lib/Transforms/Instrumentation/ValueProfilePlugins.inc
llvm/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp
llvm/lib/Transforms/Utils/CallPromotionUtils.cpp
llvm/lib/Transforms/Utils/Evaluator.cpp
llvm/lib/Transforms/Utils/InlineFunction.cpp
llvm/lib/Transforms/Utils/Local.cpp
llvm/lib/Transforms/Utils/LowerInvoke.cpp
llvm/lib/Transforms/Utils/SimplifyCFG.cpp
llvm/test/LTO/X86/type-mapping-bug3.ll
llvm/tools/llvm-diff/DiffConsumer.cpp
llvm/tools/llvm-diff/DifferenceEngine.cpp
mlir/lib/Target/LLVMIR/ConvertFromLLVMIR.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index b3fda6bd4ea3..e0e895f202c2 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2701,10 +2701,10 @@ static llvm::Value 
*tryEmitFusedAutoreleaseOfResult(CodeGenFunction &CGF,
 
   bool doRetainAutorelease;
 
-  if (call->getCalledValue() == CGF.CGM.getObjCEntrypoints().objc_retain) {
+  if (call->getCalledOperand() == CGF.CGM.getObjCEntrypoints().objc_retain) {
 doRetainAutorelease = true;
-  } else if (call->getCalledValue() == CGF.CGM.getObjCEntrypoints()
-  .objc_retainAutoreleasedReturnValue) 
{
+  } else if (call->getCalledOperand() ==
+ CGF.CGM.getObjCEntrypoints().objc_re

[Lldb-commits] [PATCH] D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error.

2020-04-27 Thread Greg Clayton via Phabricator via lldb-commits

clayborg added a comment.

In D78825#2002598 , @vsk wrote:

> Can we delete an override of SBDebugger::RunCommandInterpreter, or are they 
> all part of the stable API? If we can, it'd be nice to get rid of the one 
> with 6 args.


We can't remove any existing API because it is stable, yes.

See my inline comment and let me know your thoughts.




Comment at: lldb/include/lldb/API/SBDebugger.h:300-303
+  void RunCommandInterpreter(bool auto_handle_events, bool spawn_thread,
+ SBCommandInterpreterRunOptions &options,
+ int &num_errors, bool &quit_requested,
+ bool &stopped_for_crash, bool &stopped_for_error);

I'd vote to add a new function like:
```
SBCommandInterpreterRunResults 
RunCommandInterpreter(SBCommandInterpreterRunOptions &options);
```
We would need to add "auto_handle_events" and "spawn_thread" to 
SBCommandInterpreterRunOptions:
```
class LLDB_API SBCommandInterpreterRunOptions {
  friend class SBDebugger;
  friend class SBCommandInterpreter;

public:
  bool GetAutoHandleEvents() const;
  void SetAutoHandleEvents(bool);

  bool GetSpawnThread() const;
  void SetSpawnThread(bool);

```
and then we have an object: SBCommandInterpreterRunResults that we can query 
for number of errors, quit requested, stopped_for_crash, and stopped_for_error 
using accessors. This allows us to add new accessors without changing the API.




Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D78825



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

[Lldb-commits] [lldb] b58af8d - [lldb] Improve error message when --func-regex parameter for the breakpoint command is invalid

[Lldb-commits] [PATCH] D78808: [lldb] Improve error message when --func-regex parameter for the breakpoint command is invalid

[Lldb-commits] [lldb] 84c398d - [lldb][TypeSystemClang] Desugar an elaborated type before checking if it's a typedef or getting a typedefed type

[Lldb-commits] [PATCH] D78697: [lldb][TypeSystemClang] Desugar an elaborated type before checking if it's a typedef or getting a typedefed type

[Lldb-commits] [PATCH] D78697: [lldb][TypeSystemClang] Desugar an elaborated type before checking if it's a typedef or getting a typedefed type

[Lldb-commits] [PATCH] D78882: [IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand().

[Lldb-commits] [PATCH] D78882: [IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand().

[Lldb-commits] [PATCH] D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error.

[Lldb-commits] [PATCH] D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error.

[Lldb-commits] [PATCH] D78462: get rid of PythonInteger::GetInteger()

[Lldb-commits] [PATCH] D78396: [lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets

[Lldb-commits] [PATCH] D78839: [lldb-vscode] Add an option for loading core files

[Lldb-commits] [PATCH] D78801: [LLDB] Add class ProcessWasm for WebAssembly debugging

[Lldb-commits] [lldb] d00eaa0 - [lldb] Adjust TestExec code to be closer to real world code

[Lldb-commits] [PATCH] D78801: [LLDB] Add class ProcessWasm for WebAssembly debugging

[Lldb-commits] [PATCH] D75241: [lldb] Adjust TestExec code to be closer to real world code

[Lldb-commits] [lldb] ff5264f - [lldb][cmake] Move the remove_module_flags call to the right place in debugserver's CMakeLists

[Lldb-commits] [PATCH] D73206: Pass `CompileUnit *` along `DWARFDIE` for DWZ

[Lldb-commits] [PATCH] D77043: Fix process gdb-remote usage of value_regs/invalidate_regs

[Lldb-commits] [lldb] 18e96a3 - [lldb/unittests] Skip IPv6 test on systems which don't have IPv6 configured

[Lldb-commits] [PATCH] D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error.

[Lldb-commits] [lldb] 58435f6 - [lldb] Fix windows build break from 18e96a31

[Lldb-commits] [lldb] 8f5beb4 - [lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets.

[Lldb-commits] [PATCH] D78396: [lldb/Dataformatter] Add support for CoreFoundation Dictionaries and Sets

[Lldb-commits] [lldb] 4d40d66 - Fix up a clang-tidy nit about using empty rather than size == 0.

[Lldb-commits] [PATCH] D78839: [lldb-vscode] Add an option for loading core files

[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

[Lldb-commits] [PATCH] D78978: [LLDB] Add support for WebAssembly debugging

[Lldb-commits] [PATCH] D78801: [LLDB] Add class ProcessWasm for WebAssembly debugging

[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

[Lldb-commits] [PATCH] D78972: Treat hasWeakODRLinkage symbols as external in REPL computations

[Lldb-commits] [PATCH] D75607: [lldb] Use llvm::MC for register numbers in AArch64 ABIs

[Lldb-commits] [lldb] a58b62b - [IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand().

[Lldb-commits] [PATCH] D78825: [lldb/Driver] Exit with a non-zero exit code in batch mode when stopping because of an error.

35 matches

Site Navigation

Mail list logo

Footer information