[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Looks fine to me, with some inline ideas you can implement if you think they're 
worthwhile.

Also, since you're looking at reducing test time, the question you can ask 
yourself is: is it really worth it running separate dwarf+dsym flavours of 
these tests? I'm of the view that this should not be necessary, as the data 
formatters operate on high level abstractions, which should hide any 
differences in the debug info format (and the fact that the debug info parsers 
generate correct and consistent abstractions should be tested elsewhere). 
However, I don't have a horse in this race, so the decision is entirely up to 
you...




Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py:21-23
+def setUp(self):
+# Call super's setUp().
+ObjCDataFormatterTestCase.setUp(self)

I'm pretty sure these are unneeded, as all you do is call the overridden method.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py:29-32
+self.cf_data_formatter_commands()
+
+def cf_data_formatter_commands(self):
+"""Test formatters for Core OSX frameworks."""

I think this pattern is a relict from the days when we didn't have the magic 
test multiplicator. In those days, tests were written as:
```
def test_foo_dsym(self):
  self.buildDsym()
  self.foo()

def test_foo_dwarf(self):
  self.buildDwarf()
  self.foo()

def foo(self):
  # do the real stuff here
```

However, now that we can generate test flavours automatically, I don't think it 
makes much sense. So, unless you find it useful for some reason, I think we can 
just remove the helper function (by deleting these four lines).



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py:45-53
+# This is the function to remove the custom formats in order to have a
+# clean slate for the next test case.
+def cleanup():
+self.runCmd('type format clear', check=False)
+self.runCmd('type summary clear', check=False)
+self.runCmd('type synth clear', check=False)
+

It doesn't look like this test is doing anything to the type summaries, so I 
don't think it's necessary to clean up anything here.


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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60172: Renamed Target::GetSharedModule to AddModule, allow for ModulesDidLoad to be delayed when batch adding Modules

2019-04-05 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D60172#1455767 , @jasonmolenda 
wrote:

> Thanks Pavel, I'll convert this to use Expected<> while I'm working on it.  
> I'm writing a test case right now, and looking at how DynamicPluginDarwin 
> works more closely for adding & removing binaries, e.g. there's also no way 
> to batch remove libraries and have a group broadcast notification be sent.  
> There was also a bug in my original patch for calling 
> LoadScriptingResourceForModule() to find a python resource file in a dSYM 
> bundle - it is currently called from Target::ModuleUpdated when a binary is 
> added to the target's ModuleList, but I'm suppressing that call with this 
> change, so I need to move that over to ModulesDidLoad.


Sounds good to me.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60172



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


[Lldb-commits] [PATCH] D60271: PDBFPO: Use references instead of pointers, where possible

2019-04-05 Thread Aleksandr Urakov via Phabricator via lldb-commits
aleksandr.urakov accepted this revision.
aleksandr.urakov added a comment.

LGTM too!


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

https://reviews.llvm.org/D60271



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


[Lldb-commits] [lldb] r357744 - PDBFPO: Use references instead of pointers, where possible

2019-04-05 Thread Pavel Labath via lldb-commits
Author: labath
Date: Fri Apr  5 00:28:52 2019
New Revision: 357744

URL: http://llvm.org/viewvc/llvm-project?rev=357744&view=rev
Log:
PDBFPO: Use references instead of pointers, where possible

Summary:
The code was passing pointers around, expecting they would be not null.
In c++ it is possible to convey this notion explicitly by using a
reference instead.

Not all uses of pointers could be converted to references (e.g. one
can't store references in a container), but this will at least make it
locally obvious that code is dealing with nonnull pointers.

Reviewers: aleksandr.urakov, amccarth

Subscribers: lldb-commits

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

Modified:

lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp

Modified: 
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp?rev=357744&r1=357743&r2=357744&view=diff
==
--- 
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp
 Fri Apr  5 00:28:52 2019
@@ -53,7 +53,7 @@ protected:
 
 public:
   virtual ~FPOProgramNode() = default;
-  virtual void Accept(FPOProgramASTVisitor *visitor) = 0;
+  virtual void Accept(FPOProgramASTVisitor &visitor) = 0;
 
   Kind GetKind() const { return m_token_kind; }
 
@@ -66,7 +66,7 @@ public:
   FPOProgramNodeSymbol(llvm::StringRef name)
   : FPOProgramNode(Symbol), m_name(name) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   llvm::StringRef GetName() const { return m_name; }
 
@@ -79,7 +79,7 @@ public:
   FPOProgramNodeRegisterRef(uint32_t lldb_reg_num)
   : FPOProgramNode(Register), m_lldb_reg_num(lldb_reg_num) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   uint32_t GetLLDBRegNum() const { return m_lldb_reg_num; }
 
@@ -92,7 +92,7 @@ public:
   FPOProgramNodeIntegerLiteral(uint32_t value)
   : FPOProgramNode(IntegerLiteral), m_value(value) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   uint32_t GetValue() const { return m_value; }
 
@@ -108,12 +108,12 @@ public:
 Align,
   };
 
-  FPOProgramNodeBinaryOp(OpType op_type, FPOProgramNode *left,
- FPOProgramNode *right)
-  : FPOProgramNode(BinaryOp), m_op_type(op_type), m_left(left),
-m_right(right) {}
+  FPOProgramNodeBinaryOp(OpType op_type, FPOProgramNode &left,
+ FPOProgramNode &right)
+  : FPOProgramNode(BinaryOp), m_op_type(op_type), m_left(&left),
+m_right(&right) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   OpType GetOpType() const { return m_op_type; }
 
@@ -135,10 +135,10 @@ public:
 Deref,
   };
 
-  FPOProgramNodeUnaryOp(OpType op_type, FPOProgramNode *operand)
-  : FPOProgramNode(UnaryOp), m_op_type(op_type), m_operand(operand) {}
+  FPOProgramNodeUnaryOp(OpType op_type, FPOProgramNode &operand)
+  : FPOProgramNode(UnaryOp), m_op_type(op_type), m_operand(&operand) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   OpType GetOpType() const { return m_op_type; }
 
@@ -154,31 +154,31 @@ class FPOProgramASTVisitor {
 public:
   virtual ~FPOProgramASTVisitor() = default;
 
-  virtual void Visit(FPOProgramNodeSymbol *node) {}
-  virtual void Visit(FPOProgramNodeRegisterRef *node) {}
-  virtual void Visit(FPOProgramNodeIntegerLiteral *node) {}
-  virtual void Visit(FPOProgramNodeBinaryOp *node) {}
-  virtual void Visit(FPOProgramNodeUnaryOp *node) {}
+  virtual void Visit(FPOProgramNodeSymbol &node) {}
+  virtual void Visit(FPOProgramNodeRegisterRef &node) {}
+  virtual void Visit(FPOProgramNodeIntegerLiteral &node) {}
+  virtual void Visit(FPOProgramNodeBinaryOp &node) {}
+  virtual void Visit(FPOProgramNodeUnaryOp &node) {}
 };
 
-void FPOProgramNodeSymbol::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Visit(this);
+void FPOProgramNodeSymbol::Accept(FPOProgramASTVisitor &visitor) {
+  visitor.Visit(*this);
 }
 
-void FPOProgramNodeRegisterRef::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Visit(this);
+void FPOProgramNodeRegisterRef::Accept(FPOProgramASTVisitor &visitor) {
+  visitor.Visit(*this);
 }
 
-void FPOProgramNodeIntegerLiteral::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Visit(this);
+void FPOProgramNodeIntegerLiteral::Accept(FPOProgramASTVisitor &visitor) {
+  visitor.Visit(*this);
 }
 
-void FPOProgramNodeBinaryOp::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Vis

[Lldb-commits] [PATCH] D60271: PDBFPO: Use references instead of pointers, where possible

2019-04-05 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D60271#1455106 , @amccarth wrote:

> I noticed this also deleted two overloads of Visit from 
> FPOProgramASTVisitorDWARFCodegen, but that appears to be harmless (the base 
> class overloads were also no-ops).


Yep, that was a drive-by cleanup :P.


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

https://reviews.llvm.org/D60271



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


[Lldb-commits] [PATCH] D60271: PDBFPO: Use references instead of pointers, where possible

2019-04-05 Thread Pavel Labath via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL357744: PDBFPO: Use references instead of pointers, where 
possible (authored by labath, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D60271

Files:
  
lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp

Index: lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/NativePDB/PdbFPOProgramToDWARFExpression.cpp
@@ -53,7 +53,7 @@
 
 public:
   virtual ~FPOProgramNode() = default;
-  virtual void Accept(FPOProgramASTVisitor *visitor) = 0;
+  virtual void Accept(FPOProgramASTVisitor &visitor) = 0;
 
   Kind GetKind() const { return m_token_kind; }
 
@@ -66,7 +66,7 @@
   FPOProgramNodeSymbol(llvm::StringRef name)
   : FPOProgramNode(Symbol), m_name(name) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   llvm::StringRef GetName() const { return m_name; }
 
@@ -79,7 +79,7 @@
   FPOProgramNodeRegisterRef(uint32_t lldb_reg_num)
   : FPOProgramNode(Register), m_lldb_reg_num(lldb_reg_num) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   uint32_t GetLLDBRegNum() const { return m_lldb_reg_num; }
 
@@ -92,7 +92,7 @@
   FPOProgramNodeIntegerLiteral(uint32_t value)
   : FPOProgramNode(IntegerLiteral), m_value(value) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   uint32_t GetValue() const { return m_value; }
 
@@ -108,12 +108,12 @@
 Align,
   };
 
-  FPOProgramNodeBinaryOp(OpType op_type, FPOProgramNode *left,
- FPOProgramNode *right)
-  : FPOProgramNode(BinaryOp), m_op_type(op_type), m_left(left),
-m_right(right) {}
+  FPOProgramNodeBinaryOp(OpType op_type, FPOProgramNode &left,
+ FPOProgramNode &right)
+  : FPOProgramNode(BinaryOp), m_op_type(op_type), m_left(&left),
+m_right(&right) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   OpType GetOpType() const { return m_op_type; }
 
@@ -135,10 +135,10 @@
 Deref,
   };
 
-  FPOProgramNodeUnaryOp(OpType op_type, FPOProgramNode *operand)
-  : FPOProgramNode(UnaryOp), m_op_type(op_type), m_operand(operand) {}
+  FPOProgramNodeUnaryOp(OpType op_type, FPOProgramNode &operand)
+  : FPOProgramNode(UnaryOp), m_op_type(op_type), m_operand(&operand) {}
 
-  void Accept(FPOProgramASTVisitor *visitor) override;
+  void Accept(FPOProgramASTVisitor &visitor) override;
 
   OpType GetOpType() const { return m_op_type; }
 
@@ -154,31 +154,31 @@
 public:
   virtual ~FPOProgramASTVisitor() = default;
 
-  virtual void Visit(FPOProgramNodeSymbol *node) {}
-  virtual void Visit(FPOProgramNodeRegisterRef *node) {}
-  virtual void Visit(FPOProgramNodeIntegerLiteral *node) {}
-  virtual void Visit(FPOProgramNodeBinaryOp *node) {}
-  virtual void Visit(FPOProgramNodeUnaryOp *node) {}
+  virtual void Visit(FPOProgramNodeSymbol &node) {}
+  virtual void Visit(FPOProgramNodeRegisterRef &node) {}
+  virtual void Visit(FPOProgramNodeIntegerLiteral &node) {}
+  virtual void Visit(FPOProgramNodeBinaryOp &node) {}
+  virtual void Visit(FPOProgramNodeUnaryOp &node) {}
 };
 
-void FPOProgramNodeSymbol::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Visit(this);
+void FPOProgramNodeSymbol::Accept(FPOProgramASTVisitor &visitor) {
+  visitor.Visit(*this);
 }
 
-void FPOProgramNodeRegisterRef::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Visit(this);
+void FPOProgramNodeRegisterRef::Accept(FPOProgramASTVisitor &visitor) {
+  visitor.Visit(*this);
 }
 
-void FPOProgramNodeIntegerLiteral::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Visit(this);
+void FPOProgramNodeIntegerLiteral::Accept(FPOProgramASTVisitor &visitor) {
+  visitor.Visit(*this);
 }
 
-void FPOProgramNodeBinaryOp::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Visit(this);
+void FPOProgramNodeBinaryOp::Accept(FPOProgramASTVisitor &visitor) {
+  visitor.Visit(*this);
 }
 
-void FPOProgramNodeUnaryOp::Accept(FPOProgramASTVisitor *visitor) {
-  visitor->Visit(this);
+void FPOProgramNodeUnaryOp::Accept(FPOProgramASTVisitor &visitor) {
+  visitor.Visit(*this);
 }
 
 class FPOProgramASTVisitorMergeDependent : public FPOProgramASTVisitor {
@@ -191,10 +191,8 @@
   void Merge(FPOProgramNode *&node_ref);
 
 private:
-  void Visit(FPOProgramNodeRegisterRef *node) override {}
-  void Visit(FPOProgramNodeIntegerLiteral *node) override {}
-  void Visit(FPOProgra

[Lldb-commits] [lldb] r357747 - TestVCCode_step: replace assertTrue with more specific assertions

2019-04-05 Thread Pavel Labath via lldb-commits
Author: labath
Date: Fri Apr  5 00:56:26 2019
New Revision: 357747

URL: http://llvm.org/viewvc/llvm-project?rev=357747&view=rev
Log:
TestVCCode_step: replace assertTrue with more specific assertions

When this test fails (flakes) all we get is an error message like "False
is not True". This replaces patterns like assertTrue(a == b) with
assertEqual(a, b), so we get a better error message (and hopefully a
hint as to why the test is flaky).

Modified:

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py?rev=357747&r1=357746&r2=357747&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py
 Fri Apr  5 00:56:26 2019
@@ -32,7 +32,7 @@ class TestVSCode_step(lldbvscode_testcas
 lines = [breakpoint1_line]
 # Set breakoint in the thread function so we can step the threads
 breakpoint_ids = self.set_source_breakpoints(source, lines)
-self.assertTrue(len(breakpoint_ids) == len(lines),
+self.assertEqual(len(breakpoint_ids), len(lines),
 "expect correct number of breakpoints")
 self.continue_to_breakpoints(breakpoint_ids)
 threads = self.vscode.get_threads()
@@ -56,24 +56,24 @@ class TestVSCode_step(lldbvscode_testcas
 self.stepIn(threadId=tid, waitForStop=True)
 x2 = self.get_local_as_int('x', threadId=tid)
 (src2, line2) = self.get_source_and_line(threadId=tid)
-self.assertTrue(x1 == x2 + 1, 'verify step in variable')
-self.assertTrue(line2 < line1, 'verify step in line')
-self.assertTrue(src1 == src2, 'verify step in source')
+self.assertEqual(x1, x2 + 1, 'verify step in variable')
+self.assertLess(line2, line1, 'verify step in line')
+self.assertEqual(src1, src2, 'verify step in source')
 
 # Now step out and verify
 self.stepOut(threadId=tid, waitForStop=True)
 x3 = self.get_local_as_int('x', threadId=tid)
 (src3, line3) = self.get_source_and_line(threadId=tid)
-self.assertTrue(x1 == x3, 'verify step out variable')
-self.assertTrue(line3 >= line1, 'verify step out line')
-self.assertTrue(src1 == src3, 'verify step in source')
+self.assertEqual(x1, x3, 'verify step out variable')
+self.assertGreaterEqual(line3, line1, 'verify step out 
line')
+self.assertEqual(src1, src3, 'verify step in source')
 
 # Step over and verify
 self.stepOver(threadId=tid, waitForStop=True)
 x4 = self.get_local_as_int('x', threadId=tid)
 (src4, line4) = self.get_source_and_line(threadId=tid)
-self.assertTrue(x4 == x3, 'verify step over variable')
-self.assertTrue(line4 > line3, 'verify step over line')
-self.assertTrue(src1 == src4, 'verify step over source')
+self.assertEqual(x4, x3, 'verify step over variable')
+self.assertGreater(line4, line3, 'verify step over line')
+self.assertEqual(src1, src4, 'verify step over source')
 # only step one thread that is at the breakpoint and stop
 break


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


[Lldb-commits] [lldb] r357748 - MinidumpParser: use minidump parser in llvm/Object

2019-04-05 Thread Pavel Labath via lldb-commits
Author: labath
Date: Fri Apr  5 00:56:39 2019
New Revision: 357748

URL: http://llvm.org/viewvc/llvm-project?rev=357748&view=rev
Log:
MinidumpParser: use minidump parser in llvm/Object

This patch removes the lower layers of the minidump parsing code from
the MinidumpParser class, and replaces it with the minidump parser in
llvm.

Not all functionality is already avaiable in the llvm class, but it is
enough for us to be able to stop enumerating streams manually, and rely
on the minidump directory parsing code from the llvm class.

This also removes some checked-in binaries which were used to test error
handling in the parser, as the error handling is now done (and tested)
in llvm. Instead I just add one test that ensures we correctly propagate
the errors reported by the llvm parser. The input for this test can be
written in yaml instead of a checked-in binary.

Removed:
lldb/trunk/unittests/Process/minidump/Inputs/bad_duplicate_streams.dmp
lldb/trunk/unittests/Process/minidump/Inputs/bad_overlapping_streams.dmp
Modified:
lldb/trunk/lit/Minidump/dump-all.test
lldb/trunk/lit/Minidump/fb-dump.test
lldb/trunk/source/Plugins/Process/minidump/CMakeLists.txt
lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.cpp
lldb/trunk/source/Plugins/Process/minidump/MinidumpParser.h
lldb/trunk/source/Plugins/Process/minidump/ProcessMinidump.cpp
lldb/trunk/unittests/Process/minidump/CMakeLists.txt
lldb/trunk/unittests/Process/minidump/MinidumpParserTest.cpp

Modified: lldb/trunk/lit/Minidump/dump-all.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Minidump/dump-all.test?rev=357748&r1=357747&r2=357748&view=diff
==
--- lldb/trunk/lit/Minidump/dump-all.test (original)
+++ lldb/trunk/lit/Minidump/dump-all.test Fri Apr  5 00:56:39 2019
@@ -40,17 +40,17 @@
 # CHECKDIR:  RVASIZE   TYPE   StreamType
 # CHECKDIR-NEXT: -- -- -- --
 # CHECKDIR-NEXT: 0x00b0 0x0038 0x0007 SystemInfo
-# CHECKDIR-NEXT: 0x015d 0x001b 0x47670007 LinuxEnviron
-# CHECKDIR-NEXT: 0x0190 0x00bc 0x47670009 LinuxMaps
-# CHECKDIR-NEXT: 0x0110 0x001a 0x47670004 LinuxProcStatus
-# CHECKDIR-NEXT: 0x024c 0x0018 0x4767000b LinuxProcStat
-# CHECKDIR-NEXT: 0x0142 0x001b 0x47670006 LinuxCMDLine
-# CHECKDIR-NEXT: 0x0272 0x0016 0x4767000d LinuxProcFD
-# CHECKDIR-NEXT: 0x0178 0x0018 0x47670008 LinuxAuxv
 # CHECKDIR-NEXT: 0x00e8 0x0018 0x000f MiscInfo
 # CHECKDIR-NEXT: 0x0100 0x0010 0x47670003 LinuxCPUInfo
+# CHECKDIR-NEXT: 0x0110 0x001a 0x47670004 LinuxProcStatus
 # CHECKDIR-NEXT: 0x012a 0x0018 0x47670005 LinuxLSBRelease
+# CHECKDIR-NEXT: 0x0142 0x001b 0x47670006 LinuxCMDLine
+# CHECKDIR-NEXT: 0x015d 0x001b 0x47670007 LinuxEnviron
+# CHECKDIR-NEXT: 0x0178 0x0018 0x47670008 LinuxAuxv
+# CHECKDIR-NEXT: 0x0190 0x00bc 0x47670009 LinuxMaps
+# CHECKDIR-NEXT: 0x024c 0x0018 0x4767000b LinuxProcStat
 # CHECKDIR-NEXT: 0x0264 0x000e 0x4767000c LinuxProcUptime
+# CHECKDIR-NEXT: 0x0272 0x0016 0x4767000d LinuxProcFD
 
 # CHECKCPU:  /proc/cpuinfo:
 # CHECKCPU-NEXT: cpu info output

Modified: lldb/trunk/lit/Minidump/fb-dump.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Minidump/fb-dump.test?rev=357748&r1=357747&r2=357748&view=diff
==
--- lldb/trunk/lit/Minidump/fb-dump.test (original)
+++ lldb/trunk/lit/Minidump/fb-dump.test Fri Apr  5 00:56:39 2019
@@ -57,19 +57,19 @@
 # RUN:   FileCheck --check-prefix=CHECK-LOGCAT %s
 # CHECK-DIR:  RVASIZE   TYPE   StreamType
 # CHECK-DIR-NEXT: -- -- -- --
+# CHECK-DIR-NEXT: 0x00bc 0x0038 0x0007 SystemInfo
+# CHECK-DIR-NEXT: 0x00f4 0x0018 0x000f MiscInfo
 # CHECK-DIR-NEXT: 0x010c 0x0013 0xfacecb00 FacebookDumpErrorLog
 # CHECK-DIR-NEXT: 0x011f 0x0015 0xfacee000 FacebookThreadName
+# CHECK-DIR-NEXT: 0x0134 0x0010 0xface1ca7 FacebookLogcat
+# CHECK-DIR-NEXT: 0x0144 0x0017 0xface FacebookAppStateLog
 # CHECK-DIR-NEXT: 0x015b 0x0016 0xfacedead FacebookAbortReason
-# CHECK-DIR-NEXT: 0x00bc 0x0038 0x0007 SystemInfo
-# CHECK-DIR-NEXT: 0x01aa 0x0005 0xfacecafb FacebookBuildID
-# CHECK-DIR-NEXT: 0x01bc 0x0019 0xfacecafd FacebookJavaStack
-# CHECK-DIR-NEXT: 0x01ea 0x0005 0xfacecaff FacebookUnwindSymbols
 # CHECK-DIR-NEXT: 0x0171 0x0039 0xfacecafa FacebookAppCustomData
-# CHECK-DIR-NEXT: 0x0134 0x0010 0xface1ca7 FacebookLogcat
-# CHECK-DIR-NEXT: 0x00f4 0x0018 0x000f MiscInfo
+# CHECK-DIR-NEXT: 0x01aa 0x0005 0xfacecafb FacebookBuildID
 # CHECK-DIR-NEXT: 0x01af 0x000d 0xfacecafc FacebookAppVersionName
+# CH

[Lldb-commits] [PATCH] D60153: Re-enable most lldb-vscode tests on Linux.

2019-04-05 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

You might be interested to know that I've just seen TestVSCode_step flake (so 
far just once out of ~dozen runs) locally. I've committed r357747 to get a 
better error message if it happens again.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60153



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


[Lldb-commits] [PATCH] D59775: Minidump: Add support for reading/writing strings

2019-04-05 Thread Pavel Labath via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL357749: Minidump: Add support for reading/writing strings 
(authored by labath, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D59775?vs=193698&id=193842#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D59775

Files:
  llvm/trunk/include/llvm/Object/Minidump.h
  llvm/trunk/include/llvm/ObjectYAML/MinidumpYAML.h
  llvm/trunk/lib/Object/Minidump.cpp
  llvm/trunk/lib/ObjectYAML/MinidumpYAML.cpp
  llvm/trunk/test/tools/obj2yaml/basic-minidump.yaml
  llvm/trunk/unittests/Object/MinidumpTest.cpp
  llvm/trunk/unittests/ObjectYAML/MinidumpYAMLTest.cpp

Index: llvm/trunk/test/tools/obj2yaml/basic-minidump.yaml
===
--- llvm/trunk/test/tools/obj2yaml/basic-minidump.yaml
+++ llvm/trunk/test/tools/obj2yaml/basic-minidump.yaml
@@ -5,7 +5,7 @@
   - Type:SystemInfo
 Processor Arch:  ARM64
 Platform ID: Linux
-CSD Version RVA: 0x01020304
+CSD Version: Linux 3.13.0-91-generic
 CPU: 
   CPUID:   0x05060708
   - Type:LinuxAuxv
@@ -22,7 +22,7 @@
 # CHECK-NEXT:   - Type:SystemInfo
 # CHECK-NEXT: Processor Arch:  ARM64
 # CHECK-NEXT: Platform ID: Linux
-# CHECK-NEXT: CSD Version RVA: 0x01020304
+# CHECK-NEXT: CSD Version: Linux 3.13.0-91-generic
 # CHECK-NEXT: CPU: 
 # CHECK-NEXT:   CPUID:   0x05060708
 # CHECK-NEXT:   - Type:LinuxAuxv
Index: llvm/trunk/lib/ObjectYAML/MinidumpYAML.cpp
===
--- llvm/trunk/lib/ObjectYAML/MinidumpYAML.cpp
+++ llvm/trunk/lib/ObjectYAML/MinidumpYAML.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "llvm/ObjectYAML/MinidumpYAML.h"
+#include "llvm/Support/ConvertUTF.h"
 
 using namespace llvm;
 using namespace llvm::MinidumpYAML;
@@ -39,6 +40,8 @@
 return allocateArray(makeArrayRef(Data));
   }
 
+  size_t allocateString(StringRef Str);
+
   void writeTo(raw_ostream &OS) const;
 
 private:
@@ -48,6 +51,26 @@
 };
 } // namespace
 
+size_t BlobAllocator::allocateString(StringRef Str) {
+  SmallVector WStr;
+  bool OK = convertUTF8ToUTF16String(Str, WStr);
+  assert(OK && "Invalid UTF8 in Str?");
+  (void)OK;
+
+  SmallVector EndianStr(WStr.size() + 1,
+  support::ulittle16_t());
+  copy(WStr, EndianStr.begin());
+  return allocateCallback(
+  sizeof(uint32_t) + EndianStr.size() * sizeof(support::ulittle16_t),
+  [EndianStr](raw_ostream &OS) {
+// Length does not include the null-terminator.
+support::ulittle32_t Length(2 * (EndianStr.size() - 1));
+OS.write(reinterpret_cast(&Length), sizeof(Length));
+OS.write(reinterpret_cast(EndianStr.begin()),
+ sizeof(support::ulittle16_t) * EndianStr.size());
+  });
+}
+
 void BlobAllocator::writeTo(raw_ostream &OS) const {
   size_t BeginOffset = OS.tell();
   for (const auto &Callback : Callbacks)
@@ -269,7 +292,7 @@
   mapOptional(IO, "Minor Version", Info.MinorVersion, 0);
   mapOptional(IO, "Build Number", Info.BuildNumber, 0);
   IO.mapRequired("Platform ID", Info.PlatformId);
-  mapOptionalHex(IO, "CSD Version RVA", Info.CSDVersionRVA, 0);
+  IO.mapOptional("CSD Version", Stream.CSDVersion, "");
   mapOptionalHex(IO, "Suite Mask", Info.SuiteMask, 0);
   mapOptionalHex(IO, "Reserved", Info.Reserved, 0);
   switch (static_cast(Info.ProcessorArch)) {
@@ -337,6 +360,7 @@
   Directory Result;
   Result.Type = S.Type;
   Result.Location.RVA = File.tell();
+  Optional DataEnd;
   switch (S.Kind) {
   case Stream::StreamKind::RawContent: {
 RawContentStream &Raw = cast(S);
@@ -347,14 +371,22 @@
 });
 break;
   }
-  case Stream::StreamKind::SystemInfo:
-File.allocateObject(cast(S).Info);
+  case Stream::StreamKind::SystemInfo: {
+SystemInfoStream &SystemInfo = cast(S);
+File.allocateObject(SystemInfo.Info);
+// The CSD string is not a part of the stream.
+DataEnd = File.tell();
+SystemInfo.Info.CSDVersionRVA = File.allocateString(SystemInfo.CSDVersion);
 break;
+  }
   case Stream::StreamKind::TextContent:
 File.allocateArray(arrayRefFromStringRef(cast(S).Text));
 break;
   }
-  Result.Location.DataSize = File.tell() - Result.Location.RVA;
+  // If DataEnd is not set, we assume everything we generated is a part of the
+  // stream.
+  Result.Location.DataSize =
+  DataEnd.getValueOr(File.tell()) - Result.Location.RVA;
   return Result;
 }
 
@@ -395,7 +427,11 @@
 auto ExpectedInfo = File.getSystemInfo();
 if (!ExpectedInfo)
   return ExpectedInfo.takeError();
-return make_unique(*ExpectedInfo);
+auto ExpectedCSDVersion = File.getString(ExpectedInfo->CSDVersionRVA);
+  

[Lldb-commits] [PATCH] D60268: Breakpad: Parse Stack CFI records

2019-04-05 Thread Pavel Labath via Phabricator via lldb-commits
labath marked 3 inline comments as done.
labath added inline comments.



Comment at: source/Plugins/ObjectFile/Breakpad/BreakpadRecords.h:173
+  llvm::DenseMap UnwindRules;
+};
+

amccarth wrote:
> I'm not a fan of deep class hierarchies, but given that StackCFIRecord is a 
> subset of StackCFIInitRecord and given that the naming suggests 
> StackCFIInitRecord is a concrete type of StackCFIRecord, should 
> StackCFIInitRecord derive from StackCFIRecord?  (Or perhaps contain one?)
> 
> If not, perhaps a comment to explain why not.
Good question. I was doing the same thing as I did with FUNC and PUBLIC 
records, which are also very similar, but I wouln't be comfortable saying one 
is a special case of the other. However, the case here is not as clear, as one 
could consider the "init" record to be a special kind of a "stack cfi" record.  
OTOH, I also don't like deep hierarchies and particularly having a concrete 
class (init record) inherit from another concrete class (stack cfi record).

Since this code is likely to have only a single consumer (the thing which 
converts these into UnwindPlans), adding an AbstractCFIRecord class would seem 
like an overkill. Instead, how about we just collapse things even more and use 
just a single class to represent both records (with an Optional for the 
size)?

I don't think this should make it the job of the consumer much harder, but it 
will allow us to:
- avoid needing special code to group these two records together
- give us an excuse to call this group (section) "STACK CFI". (I have 
previously called this group "STACK CFI INIT" for consistency with how the 
FUNC+LINE groups is handled, but that didn't feel quite right here).
- speed up parsing as we don't have to parse the "STACK CFI" part twice just to 
find out we're not parsing the correct record type.



Comment at: unittests/ObjectFile/Breakpad/BreakpadRecordsTest.cpp:123
+"STACK CFI 47 .cfa: $esp 4 + $eip: .cfa 4 - ^"));
+}
+

amccarth wrote:
> All of the negative parsing tests seem to be incomplete (e.g., truncated or a 
> missing `INIT`).  Should there be others, like having the wrong token type?  
> Or an invalid token?  Or one that has extra tokens at the end of an otherwise 
> valid record?
> 
> I see you're following the pattern for the other types here, but is that 
> enough?
Following the pattern isn't much of an excuse for me, as I was the one who 
established that pattern. :)

The reason the pattern is like it is was that I was trying to cover all of the 
paths through the parsing code. I believe I have succeeded at that, but I 
haven't used a profiler or anything to verify that. Knowing the implementation, 
it's obvious that a test with an invalid record type is not going to be 
interesting, as we will bail out straight after the first token. However, I 
agree that from a black-box testing perspective, these are interesting cases to 
check, so I've added a couple more that I could think of.

This is going to be the most extensively tested piece of code in lldb :P.



Comment at: unittests/ObjectFile/Breakpad/BreakpadRecordsTest.cpp:132
+StackCFIRecord::parse("STACK CFI INIT 47 8 .cfa: $esp 4 +"));
+}

amccarth wrote:
> This test relies on the parsing test for the StackCFIInitRecord having 
> covered most of the cases.  That works because the parsing implementation is 
> shared, so I'm OK with it.  Will others be concerned that this test isn't as 
> independent as it could be?
Another advantage of merging the two record types is that it makes this comment 
void. :)


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

https://reviews.llvm.org/D60268



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


[Lldb-commits] [PATCH] D60268: Breakpad: Parse Stack CFI records

2019-04-05 Thread Pavel Labath via Phabricator via lldb-commits
labath updated this revision to Diff 193849.
labath added a comment.

merge StackCFI and StackCFIInit records
add some tests


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

https://reviews.llvm.org/D60268

Files:
  source/Plugins/ObjectFile/Breakpad/BreakpadRecords.cpp
  source/Plugins/ObjectFile/Breakpad/BreakpadRecords.h
  source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp
  unittests/ObjectFile/Breakpad/BreakpadRecordsTest.cpp

Index: unittests/ObjectFile/Breakpad/BreakpadRecordsTest.cpp
===
--- unittests/ObjectFile/Breakpad/BreakpadRecordsTest.cpp
+++ unittests/ObjectFile/Breakpad/BreakpadRecordsTest.cpp
@@ -19,7 +19,6 @@
   EXPECT_EQ(Record::File, Record::classify("FILE"));
   EXPECT_EQ(Record::Func, Record::classify("FUNC"));
   EXPECT_EQ(Record::Public, Record::classify("PUBLIC"));
-  EXPECT_EQ(Record::StackCFIInit, Record::classify("STACK CFI INIT"));
   EXPECT_EQ(Record::StackCFI, Record::classify("STACK CFI"));
 
   // Any obviously incorrect lines will be classified as such.
@@ -97,3 +96,41 @@
   EXPECT_EQ(llvm::None, PublicRecord::parse("PUBLIC m"));
   EXPECT_EQ(llvm::None, PublicRecord::parse("PUBLIC"));
 }
+
+TEST(StackCFIRecord, parse) {
+  EXPECT_EQ(
+  StackCFIRecord(0x47, 0x8, {{".cfa", "$esp 4 +"}, {"$eip", ".cfa 4 - ^"}}),
+  StackCFIRecord::parse(
+  "STACK CFI INIT 47 8 .cfa: $esp 4 + $eip: .cfa 4 - ^"));
+  EXPECT_EQ(StackCFIRecord(0x47, 0x8, {{".cfa", "$esp 4 +"}}),
+StackCFIRecord::parse("STACK CFI INIT 47 8 .cfa: $esp 4 +"));
+
+  EXPECT_EQ(
+  StackCFIRecord(0x47, llvm::None,
+ {{".cfa", "$esp 4 +"}, {"$eip", ".cfa 4 - ^"}}),
+  StackCFIRecord::parse("STACK CFI 47 .cfa: $esp 4 + $eip: .cfa 4 - ^"));
+
+  // The validity of the register value expressions is not checked
+  EXPECT_EQ(StackCFIRecord(0x47, 0x8, {{".cfa", "^ ^ ^"}}),
+StackCFIRecord::parse("STACK CFI INIT 47 8 .cfa: ^ ^ ^"));
+  EXPECT_EQ(StackCFIRecord(0x47, 0x8, {{".cfa", "STACK CFI"}}),
+StackCFIRecord::parse("STACK CFI INIT 47 8 .cfa: STACK CFI"));
+
+  EXPECT_EQ(llvm::None,
+StackCFIRecord::parse("STACK CFI INIT 47 .cfa: $esp 4 +"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("STACK CFI 47 8 .cfa: $esp 4 +"));
+  EXPECT_EQ(llvm::None,
+StackCFIRecord::parse("STACK CFI INIT 47 8 .cfa: $esp 4 + $eip:"));
+  EXPECT_EQ(llvm::None,
+StackCFIRecord::parse("STACK CFI INIT 47 8 .cfa: $eip: .cfa"));
+  EXPECT_EQ(llvm::None,
+StackCFIRecord::parse("STACK CFI INIT 47 8 $esp .cfa: $esp"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("STACK CFI INIT 47 8 .cfa:"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("STACK CFI INIT 47 8"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("STACK CFI INIT 47"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("STACK CFI INIT"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("STACK CFI"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("STACK"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("FILE 47 foo"));
+  EXPECT_EQ(llvm::None, StackCFIRecord::parse("42 47"));
+}
Index: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp
===
--- source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp
+++ source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp
@@ -153,9 +153,6 @@
   // Line records logically belong to the preceding Func record, so we put
   // them in the same section.
   next_section = Record::Func;
-} else if (next_section == Record::StackCFI) {
-  // Same goes for StackCFI and StackCFIInit
-  next_section = Record::StackCFIInit;
 }
 if (next_section == current_section)
   continue;
Index: source/Plugins/ObjectFile/Breakpad/BreakpadRecords.h
===
--- source/Plugins/ObjectFile/Breakpad/BreakpadRecords.h
+++ source/Plugins/ObjectFile/Breakpad/BreakpadRecords.h
@@ -11,6 +11,7 @@
 
 #include "lldb/Utility/UUID.h"
 #include "lldb/lldb-types.h"
+#include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Support/FormatProviders.h"
@@ -20,7 +21,7 @@
 
 class Record {
 public:
-  enum Kind { Module, Info, File, Func, Line, Public, StackCFIInit, StackCFI };
+  enum Kind { Module, Info, File, Func, Line, Public, StackCFI };
 
   /// Attempt to guess the kind of the record present in the argument without
   /// doing a full parse. The returned kind will always be correct for valid
@@ -141,6 +142,22 @@
 bool operator==(const PublicRecord &L, const PublicRecord &R);
 llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const PublicRecord &R);
 
+class StackCFIRecord : public Record {
+public:
+  static llvm::Optional parse(llvm::StringRef Line);
+  StackCFIRecord(lldb::addr_t Address, llvm::Optional Size,
+ llvm::DenseMap UnwindRules)

[Lldb-commits] [lldb] r357755 - modify-python-lldb.py: Insert initialization code with swig instead

2019-04-05 Thread Pavel Labath via lldb-commits
Author: labath
Date: Fri Apr  5 02:56:55 2019
New Revision: 357755

URL: http://llvm.org/viewvc/llvm-project?rev=357755&view=rev
Log:
modify-python-lldb.py: Insert initialization code with swig instead

This is the last functional change to the generated python module being
done by modify-python-lldb.py. The remaining code just deals with
reformatting of comments.

Modified:
lldb/trunk/scripts/Python/modify-python-lldb.py
lldb/trunk/scripts/lldb.swig

Modified: lldb/trunk/scripts/Python/modify-python-lldb.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/modify-python-lldb.py?rev=357755&r1=357754&r2=357755&view=diff
==
--- lldb/trunk/scripts/Python/modify-python-lldb.py (original)
+++ lldb/trunk/scripts/Python/modify-python-lldb.py Fri Apr  5 02:56:55 2019
@@ -166,10 +166,3 @@ new_content.finish()
 
 with open(output_name, 'w') as f_out:
 f_out.write(new_content.getvalue())
-f_out.write('''debugger_unique_id = 0
-SBDebugger.Initialize()
-debugger = None
-target = SBTarget()
-process = SBProcess()
-thread = SBThread()
-frame = SBFrame()''')

Modified: lldb/trunk/scripts/lldb.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/lldb.swig?rev=357755&r1=357754&r2=357755&view=diff
==
--- lldb/trunk/scripts/lldb.swig (original)
+++ lldb/trunk/scripts/lldb.swig Fri Apr  5 02:56:55 2019
@@ -260,3 +260,13 @@ def lldb_iter(obj, getsize, getelem):
 %include "./Python/python-extensions.swig"
 
 %include "./Python/python-wrapper.swig"
+
+%pythoncode%{
+debugger_unique_id = 0
+SBDebugger.Initialize()
+debugger = None
+target = SBTarget()
+process = SBProcess()
+thread = SBThread()
+frame = SBFrame()
+%}


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


[Lldb-commits] [PATCH] D59015: [lldb-mi] Include full path in the -data-disassemble response

2019-04-05 Thread Anton Kolesov via Phabricator via lldb-commits
anton.kolesov updated this revision to Diff 193863.
anton.kolesov added a comment.

Added a simple test case.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D59015

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
  lldb/tools/lldb-mi/MICmdCmdData.cpp


Index: lldb/tools/lldb-mi/MICmdCmdData.cpp
===
--- lldb/tools/lldb-mi/MICmdCmdData.cpp
+++ lldb/tools/lldb-mi/MICmdCmdData.cpp
@@ -415,8 +415,12 @@
   const MIuint nLine = lineEntry.GetLine();
   const char *pFileName = lineEntry.GetFileSpec().GetFilename();
   pFileName = (pFileName != nullptr) ? pFileName : pUnknown;
+  // Get a full path to the file.
+  static char pPathBuffer[PATH_MAX];
+  lineEntry.GetFileSpec().GetPath(pPathBuffer, sizeof(pPathBuffer));
 
-  // MI "src_and_asm_line={line=\"%u\",file=\"%s\",line_asm_insn=[ ]}"
+  // MI "src_and_asm_line={line=\"%u\",file=\"%s\",line_asm_insn=[ ],
+  // fullname=\"%s\"}"
   const CMICmnMIValueConst miValueConst(
   CMIUtilString::Format("%u", nLine));
   const CMICmnMIValueResult miValueResult("line", miValueConst);
@@ -427,6 +431,9 @@
   const CMICmnMIValueList miValueList(miValueTuple);
   const CMICmnMIValueResult miValueResult3("line_asm_insn", miValueList);
   miValueTuple2.Add(miValueResult3);
+  const CMICmnMIValueConst miValueConst5(pPathBuffer);
+  const CMICmnMIValueResult miValueResult5("fullname", miValueConst5);
+  miValueTuple2.Add(miValueResult5);
   const CMICmnMIValueResult miValueResult4("src_and_asm_line",
miValueTuple2);
   m_miValueList.Add(miValueResult4);
Index: lldb/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
===
--- lldb/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
+++ lldb/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
@@ -56,6 +56,14 @@
 
"\^done,asm_insns=\[{address=\"0x0*%x\",func-name=\"main\",offset=\"0\",size=\"[1-9]+\",inst=\".+?\"},"
 %
 addr)
 
+# Test -data-disassemble with source line information
+self.runCmd("-data-disassemble -s %#x -e %#x -- 1" % (addr, addr + 
0x10))
+self.expect(
+'\^done,asm_insns=\[src_and_asm_line={line="\d+",file="main.cpp",'
+
'line_asm_insn=\[{address="0x0*%x",func-name="main",offset="0",size="[1-9]+",inst=".+?"}\],'
+'fullname="%s"}' %
+(addr, os.path.abspath("main.cpp")) )
+
 # Run to hello_world
 self.runCmd("-break-insert -f hello_world")
 self.expect("\^done,bkpt={number=\"2\"")


Index: lldb/tools/lldb-mi/MICmdCmdData.cpp
===
--- lldb/tools/lldb-mi/MICmdCmdData.cpp
+++ lldb/tools/lldb-mi/MICmdCmdData.cpp
@@ -415,8 +415,12 @@
   const MIuint nLine = lineEntry.GetLine();
   const char *pFileName = lineEntry.GetFileSpec().GetFilename();
   pFileName = (pFileName != nullptr) ? pFileName : pUnknown;
+  // Get a full path to the file.
+  static char pPathBuffer[PATH_MAX];
+  lineEntry.GetFileSpec().GetPath(pPathBuffer, sizeof(pPathBuffer));
 
-  // MI "src_and_asm_line={line=\"%u\",file=\"%s\",line_asm_insn=[ ]}"
+  // MI "src_and_asm_line={line=\"%u\",file=\"%s\",line_asm_insn=[ ],
+  // fullname=\"%s\"}"
   const CMICmnMIValueConst miValueConst(
   CMIUtilString::Format("%u", nLine));
   const CMICmnMIValueResult miValueResult("line", miValueConst);
@@ -427,6 +431,9 @@
   const CMICmnMIValueList miValueList(miValueTuple);
   const CMICmnMIValueResult miValueResult3("line_asm_insn", miValueList);
   miValueTuple2.Add(miValueResult3);
+  const CMICmnMIValueConst miValueConst5(pPathBuffer);
+  const CMICmnMIValueResult miValueResult5("fullname", miValueConst5);
+  miValueTuple2.Add(miValueResult5);
   const CMICmnMIValueResult miValueResult4("src_and_asm_line",
miValueTuple2);
   m_miValueList.Add(miValueResult4);
Index: lldb/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
===
--- lldb/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
+++ lldb/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py
@@ -56,6 +56,14 @@
 "\^done,asm_insns=\[{address=\"0x0*%x\",func-name=\"main\",offset=\"0\",size=\"[1-9]+\",inst=\".+?\"}," %
 addr)
 
+# Test -data-disassemble with source line information
+self.runCmd("-data-disassemble -s %#x -e %#x -- 1" % (addr, addr + 0x10))
+self.expect(
+'\^done,asm_insns=\[src_and_asm_line={line="\d+",file="main.cpp",'
+'line_asm_i

[Lldb-commits] [PATCH] D59015: [lldb-mi] Include full path in the -data-disassemble response

2019-04-05 Thread Greg Clayton via Phabricator via lldb-commits
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.



Comment at: lldb/tools/lldb-mi/MICmdCmdData.cpp:419
+  // Get a full path to the file.
+  static char pPathBuffer[PATH_MAX];
+  lineEntry.GetFileSpec().GetPath(pPathBuffer, sizeof(pPathBuffer));

This shouldn't be static. Probably not going to cause problems if this is 
always single threaded, but still you should fix this.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D59015



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


[Lldb-commits] [PATCH] D60268: Breakpad: Parse Stack CFI records

2019-04-05 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added inline comments.



Comment at: source/Plugins/ObjectFile/Breakpad/BreakpadRecords.cpp:393
+  llvm::StringRef LHS, RHS;
+  while (std::tie(Str, Line) = getToken(Line), !Str.empty()) {
+if (Str.back() == ':') { // regN

Do we really need to pull the content apart into separate strings for each 
register? Seems like a lot of work and 99% of these we will never accessed. 
Maybe just store the entire string for all registers and be done? 



Comment at: source/Plugins/ObjectFile/Breakpad/BreakpadRecords.cpp:394
+  while (std::tie(Str, Line) = getToken(Line), !Str.empty()) {
+if (Str.back() == ':') { // regN
+  // Flush the previous expression, if there is one.

Does the format specify no space between the register name and the colon?


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

https://reviews.llvm.org/D60268



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


[Lldb-commits] [PATCH] D60268: Breakpad: Parse Stack CFI records

2019-04-05 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added inline comments.



Comment at: source/Plugins/ObjectFile/Breakpad/BreakpadRecords.cpp:393
+  llvm::StringRef LHS, RHS;
+  while (std::tie(Str, Line) = getToken(Line), !Str.empty()) {
+if (Str.back() == ':') { // regN

clayborg wrote:
> Do we really need to pull the content apart into separate strings for each 
> register? Seems like a lot of work and 99% of these we will never accessed. 
> Maybe just store the entire string for all registers and be done? 
You can add an iterator method to the StackCFIRecord record maybe for when you 
do want to parse each register?


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

https://reviews.llvm.org/D60268



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


[Lldb-commits] [PATCH] D60268: Breakpad: Parse Stack CFI records

2019-04-05 Thread Adrian McCarthy via Phabricator via lldb-commits
amccarth added a comment.

My concerns were address, so LGTM.  I'll leave the rest to you and clayborg.


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

https://reviews.llvm.org/D60268



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


[Lldb-commits] [PATCH] D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds

2019-04-05 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz added a comment.

> [LLVM_LIBRARY_DIR is] not a cache variable when it's an in-tree build

Great, then please go ahead.

> From what I remember, you added back [...]

Yes this was a quick-fix. I didn't have the patience in that moment to check 
each of them individually.

> If there's a situation where any of these variables don't get propagated from 
> the LLVMConfig, I'd like to know about it so I can add comments above these 
> variables explaining why these variables are set since it's non-obvious just 
> from grepping the lldb tree.

It's usually a good idea to check both, the LLVMConfig.cmake from a build-tree 
and from an install-tree. They are quite different and LLDB standalone should 
work with both.

You can check the green dragon bot that we added recently: 
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/
It builds against both versions (and BTW it also dumps CMake cache entries).


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

https://reviews.llvm.org/D60180



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


[Lldb-commits] [PATCH] D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds

2019-04-05 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz added a comment.

> No, everything is being built for android. Cross-compiling lldb-server 
> involves cross-compiling llvm libraries, clang libraries, and if you've got 
> swift in the picture, swift host libraries. LLVM and clang libraries are 
> built against the libc++ from the android NDK, but in standalone builds, LLDB 
> will try to link against the freshly built libc++ from LLVM. You get loads of 
> undefined references to symbols from the NDK's libc++.

For the `link_directories` line: if you cross-compile the entire tree and this 
tree contains libc++, wouldn't it be natural that LLDB will try to link against 
the freshly built libc++?
If this is not your intention, then maybe we need a `LLDB_EXTERNAL_LIBCXX` 
option instead?


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

https://reviews.llvm.org/D60180



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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py:21
+# Find the line number to break at.
+self.line = line_number('main.m', '// Set break point at this line.')
+

All uses of this variable should also be replaced by 
`lldbutil.run_to_source_breakpoint()`


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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py:30
+def nsexception_data_formatter_commands(self):
+self.expect(
+'frame variable except0 except1 except2 except3',

It would be cleaner to replace
self.expect('frame var'

with lldbutil.check_variable()

but that's less important.


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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added inline comments.



Comment at: 
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py:33
+lldbutil.run_break_set_by_file_and_line(
+self, "main.m", self.line, num_expected_locations=1, 
loc_exact=True)
+

i.e.: this


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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60325: [lldb] [Process/NetBSD] Fix wrongly mapping mm* registers

2019-04-05 Thread Michał Górny via Phabricator via lldb-commits
mgorny created this revision.
mgorny added reviewers: krytarowski, labath.

Fix mistake that mapped mm* registers into the space for xmm* registers,
rather than the one shared with st* registers.  In other words,
'register read mmN' now correctly shows the mmN register rather than
part of xmmN.

Includes a minimal lit regression test.


https://reviews.llvm.org/D60325

Files:
  lldb/lit/Register/Inputs/x86-mm-xmm-read.s
  lldb/lit/Register/x86-mm-xmm-read.test
  lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp

Index: lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
===
--- lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
+++ lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
@@ -406,7 +406,7 @@
   case lldb_mm5_x86_64:
   case lldb_mm6_x86_64:
   case lldb_mm7_x86_64:
-reg_value.SetBytes(&m_fpr_x86_64.fxstate.fx_xmm[reg - lldb_mm0_x86_64],
+reg_value.SetBytes(&m_fpr_x86_64.fxstate.fx_87_ac[reg - lldb_mm0_x86_64],
reg_info->byte_size, endian::InlHostByteOrder());
 break;
   case lldb_xmm0_x86_64:
@@ -602,7 +602,7 @@
   case lldb_mm5_x86_64:
   case lldb_mm6_x86_64:
   case lldb_mm7_x86_64:
-::memcpy(&m_fpr_x86_64.fxstate.fx_xmm[reg - lldb_mm0_x86_64],
+::memcpy(&m_fpr_x86_64.fxstate.fx_87_ac[reg - lldb_mm0_x86_64],
  reg_value.GetBytes(), reg_value.GetByteSize());
 break;
   case lldb_xmm0_x86_64:
Index: lldb/lit/Register/x86-mm-xmm-read.test
===
--- /dev/null
+++ lldb/lit/Register/x86-mm-xmm-read.test
@@ -0,0 +1,22 @@
+# REQUIRES: x86
+# RUN: %clang %p/Inputs/x86-mm-xmm-read.s -o %t
+# RUN: %lldb -b -s %s %t | FileCheck %s
+process launch
+
+register read --all
+# CHECK: mm0 = 0x0102030405060708
+# CHECK-NEXT: mm1 = 0x1112131415161718
+# CHECK-NEXT: mm2 = 0x2122232425262728
+# CHECK-NEXT: mm3 = 0x3132333435363738
+# CHECK-NEXT: mm4 = 0x4142434445464748
+# CHECK-NEXT: mm5 = 0x5152535455565758
+# CHECK-NEXT: mm6 = 0x6162636465666768
+# CHECK-NEXT: mm7 = 0x7172737475767778
+# CHECK-NEXT: xmm0 = {0x01 0x0e 0x0c 0x0a 0x08 0x06 0x04 0x02 0x00 0x0f 0x0d 0x0b 0x09 0x07 0x05 0x03}
+# CHECK-NEXT: xmm1 = {0x11 0x1e 0x1c 0x1a 0x18 0x16 0x14 0x12 0x10 0x1f 0x1d 0x1b 0x19 0x17 0x15 0x13}
+# CHECK-NEXT: xmm2 = {0x21 0x2e 0x2c 0x2a 0x28 0x26 0x24 0x22 0x20 0x2f 0x2d 0x2b 0x29 0x27 0x25 0x23}
+# CHECK-NEXT: xmm3 = {0x31 0x3e 0x3c 0x3a 0x38 0x36 0x34 0x32 0x30 0x3f 0x3d 0x3b 0x39 0x37 0x35 0x33}
+# CHECK-NEXT: xmm4 = {0x41 0x4e 0x4c 0x4a 0x48 0x46 0x44 0x42 0x40 0x4f 0x4d 0x4b 0x49 0x47 0x45 0x43}
+# CHECK-NEXT: xmm5 = {0x51 0x5e 0x5c 0x5a 0x58 0x56 0x54 0x52 0x50 0x5f 0x5d 0x5b 0x59 0x57 0x55 0x53}
+# CHECK-NEXT: xmm6 = {0x61 0x6e 0x6c 0x6a 0x68 0x66 0x64 0x62 0x60 0x6f 0x6d 0x6b 0x69 0x67 0x65 0x63}
+# CHECK-NEXT: xmm7 = {0x71 0x7e 0x7c 0x7a 0x78 0x76 0x74 0x72 0x70 0x7f 0x7d 0x7b 0x79 0x77 0x75 0x73}
Index: lldb/lit/Register/Inputs/x86-mm-xmm-read.s
===
--- /dev/null
+++ lldb/lit/Register/Inputs/x86-mm-xmm-read.s
@@ -0,0 +1,63 @@
+.text
+.globl  main
+.type   main, @function
+main:
+movq.MM0, %mm0
+movq.MM1, %mm1
+movq.MM2, %mm2
+movq.MM3, %mm3
+movq.MM4, %mm4
+movq.MM5, %mm5
+movq.MM6, %mm6
+movq.MM7, %mm7
+
+movaps  .XMM0, %xmm0
+movaps  .XMM1, %xmm1
+movaps  .XMM2, %xmm2
+movaps  .XMM3, %xmm3
+movaps  .XMM4, %xmm4
+movaps  .XMM5, %xmm5
+movaps  .XMM6, %xmm6
+movaps  .XMM7, %xmm7
+
+int3
+
+movl$0, %eax
+ret
+.size   main, .-main
+
+.balign 8
+.MM0:
+.quad   0x0102030405060708
+.MM1:
+.quad   0x1112131415161718
+.MM2:
+.quad   0x2122232425262728
+.MM3:
+.quad   0x3132333435363738
+.MM4:
+.quad   0x4142434445464748
+.MM5:
+.quad   0x5152535455565758
+.MM6:
+.quad   0x6162636465666768
+.MM7:
+.quad   0x7172737475767778
+
+.balign 16
+.XMM0:
+.quad   0x020406080A0C0E01,0x030507090B0D0F00
+.XMM1:
+.quad   0x121416181A1C1E11,0x131517191B1D1F10
+.XMM2:
+.quad   0x222426282A2C2E21,0x232527292B2D2F20
+.XMM3:
+.quad   0x323436383A3C3E31,0x333537393B3D3F30
+.XMM4:
+.quad   0x424446484A4C4E41,0x434547494B4D4F40
+.XMM5:
+.quad   0x525456585A5C5E51,0x535557595B5D5F50
+.XMM6:
+.quad   0x626466686A6C6E61,0x636567696B6D6F60
+.XMM7:
+.quad   0x727476787A7C7E71,0x737577797B7D7F70
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere updated this revision to Diff 193909.
JDevlieghere marked 5 inline comments as done.
JDevlieghere added a comment.

Code review feedback


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

https://reviews.llvm.org/D60300

Files:
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCExpr.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCPlain.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
  
lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/nsstring/TestDataFormatterNSString.py

Index: lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/nsstring/TestDataFormatterNSString.py
===
--- lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/nsstring/TestDataFormatterNSString.py
+++ lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/nsstring/TestDataFormatterNSString.py
@@ -45,16 +45,19 @@
 commands()
 
 @skipUnlessDarwin
+@no_debug_info_test
 def test_nsstring_with_run_command(self):
 """Test formatters for NSString."""
 self.appkit_tester_impl(self.nsstring_data_formatter_commands)
 
 @skipUnlessDarwin
+@no_debug_info_test
 def test_rdar11106605_with_run_command(self):
 """Check that Unicode characters come out of CFString summary correctly."""
 self.appkit_tester_impl(self.rdar11106605_commands)
 
 @skipUnlessDarwin
+@no_debug_info_test
 def test_nsstring_withNULS_with_run_command(self):
 """Test formatters for NSString."""
 self.appkit_tester_impl(self.nsstring_withNULs_commands)
Index: lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
@@ -0,0 +1,36 @@
+# encoding: utf-8
+"""
+Test lldb data formatter subsystem.
+"""
+
+from __future__ import print_function
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+from ObjCDataFormatterTestCase import ObjCDataFormatterTestCase
+
+
+class ObjCDataFormatterNSException(ObjCDataFormatterTestCase):
+
+@skipUnlessDarwin
+@no_debug_info_test
+def test_nsexception_with_run_command(self):
+"""Test formatters for NSException."""
+self.appkit_tester_impl(self.nsexception_data_formatter_commands)
+
+def nsexception_data_formatter_commands(self):
+self.expect(
+'frame variable except0 except1 except2 except3',
+substrs=[
+'(NSException *) except0 = ',
+'name: @"TheGuyWhoHasNoName" - reason: @"cuz it\'s funny"',
+'(NSException *) except1 = ',
+'name: @"TheGuyWhoHasNoName~1" - reason: @"cuz it\'s funny"',
+'(NSException *) except2 = ',
+'name: @"TheGuyWhoHasNoName`2" - reason: @"cuz it\'s funny"',
+'(NSException *) except3 = ',
+'name: @"TheGuyWhoHasNoName/3" - reason: @"cuz it\'s funny"'
+])
Index: lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCPlain.py
===
--- /dev/null
+++ lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCPlain.py
@@ -0,0 +1,79 @@
+# encoding

[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

In D60300#1455790 , @davide wrote:

> I think this is good regardless for readability, but I would really 
> appreciate if we can collect some numbers to see how effective this change 
> actually is.


I see 120 -> 12 seconds on my iMac Pro.


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

https://reviews.llvm.org/D60300



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


Re: [Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Greg Clayton via lldb-commits
Nice!

> On Apr 5, 2019, at 10:52 AM, Jonas Devlieghere via Phabricator via 
> lldb-commits  wrote:
> 
> JDevlieghere added a comment.
> 
> In D60300#1455790 , @davide wrote:
> 
>> I think this is good regardless for readability, but I would really 
>> appreciate if we can collect some numbers to see how effective this change 
>> actually is.
> 
> 
> I see 120 -> 12 seconds on my iMac Pro.
> 
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D60300/new/
> 
> https://reviews.llvm.org/D60300
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Davide Italiano via Phabricator via lldb-commits
davide accepted this revision.
davide added a comment.
This revision is now accepted and ready to land.

great!


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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [lldb] r357786 - [testsuite] Split Objective-C data formatter

2019-04-05 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Fri Apr  5 10:57:40 2019
New Revision: 357786

URL: http://llvm.org/viewvc/llvm-project?rev=357786&view=rev
Log:
[testsuite] Split Objective-C data formatter

The testcase for objective-c data formatters is very big as it checks a
bunch of stuff. This is annoying when using the lit test driver, because
it prevents us from running the different cases in parallel. As a
result, it's always one of the last few tests that complete. This patch
splits the test into multiple files that share a common base class. This
way lit can run the different tests in parallel.

Differential revision: https://reviews.llvm.org/D60300

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCExpr.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCPlain.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
Removed:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/nsstring/TestDataFormatterNSString.py

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py?rev=357786&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py
 Fri Apr  5 10:57:40 2019
@@ -0,0 +1,43 @@
+# encoding: utf-8
+"""
+Test lldb data formatter subsystem.
+"""
+
+from __future__ import print_function
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class ObjCDataFormatterTestCase(TestBase):
+
+   mydir = TestBase.compute_mydir(__file__)
+
+   def appkit_tester_impl(self, commands):
+  self.build()
+  self.appkit_common_data_formatters_command()
+  commands()
+
+   def appkit_common_data_formatters_command(self):
+  """Test formatters for AppKit classes."""
+  self.target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(
+  self, '// Set break point at this line.',
+  lldb.SBFileSpec('main.m', False))
+
+  # The stop reason of the thread should be breakpoint.
+  self.expect(
+  "thread list",
+  STOPPED_DUE_TO_BREAKPOINT,
+  substrs=['stopped', 'stop reason = breakpoint'])
+
+  # This is the function to remove the custom formats in order to have a
+  # clean slate for the next test case.
+  def cleanup():
+ self.runCmd('type format clear', check=False)
+ self.runCmd('type summary clear', check=False)
+ self.runCmd('type synth clear', check=False)
+
+  # Execute the cleanup function during test case tear down.
+  self.addTearDownHook(cleanup)

Removed: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py?rev=357785&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/func

[Lldb-commits] [lldb] r357787 - Add .noindex to the gitignore

2019-04-05 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Fri Apr  5 10:57:42 2019
New Revision: 357787

URL: http://llvm.org/viewvc/llvm-project?rev=357787&view=rev
Log:
Add .noindex to the gitignore

The .noindex suffix is used on macOS to prevent Spotlight from indexing
its contents. These folders contain test output from dotest.py and
should be ignored when dotest is run from the LLDB source directory.

Modified:
lldb/trunk/.gitignore

Modified: lldb/trunk/.gitignore
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/.gitignore?rev=357787&r1=357786&r2=357787&view=diff
==
--- lldb/trunk/.gitignore (original)
+++ lldb/trunk/.gitignore Fri Apr  5 10:57:42 2019
@@ -26,6 +26,7 @@
 # OS X specific files.
 .DS_store
 DerivedData/
+*.noindex
 
 # Remote build configuration files.
 .remote-build.conf


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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

In D60300#1456468 , @JDevlieghere 
wrote:

> In D60300#1455790 , @davide wrote:
>
> > I think this is good regardless for readability, but I would really 
> > appreciate if we can collect some numbers to see how effective this change 
> > actually is.
>
>
> I see 120 -> 12 seconds on my iMac Pro.


Nice! Might be nice to have some automated info that gets dumped when one file 
with multiple tests takes a long time and suggest breaking them up in the 
python test infrastructure modules. Might be other nice gains to be had?


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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added a comment.

What's the motivation behind all the `@no_debug_info_test` decorators? Are 
those codepaths guaranteed to be tested elsewhere?


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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Jonas Devlieghere via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL357786: [testsuite] Split Objective-C data formatter 
(authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D60300?vs=193909&id=193912#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D60300

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/ObjCDataFormatterTestCase.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCExpr.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCPlain.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/nsstring/TestDataFormatterNSString.py

Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py
@@ -0,0 +1,65 @@
+# encoding: utf-8
+"""
+Test lldb data formatter subsystem.
+"""
+
+from __future__ import print_function
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+from ObjCDataFormatterTestCase import ObjCDataFormatterTestCase
+
+
+class ObjCDataFormatterKVO(ObjCDataFormatterTestCase):
+
+@skipUnlessDarwin
+@no_debug_info_test
+def test_kvo_with_run_command(self):
+"""Test the behavior of formatters when KVO is in use."""
+self.build()
+self.target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(
+self, '// Set break point at this line.',
+lldb.SBFileSpec('main.m', False))
+
+# The stop reason of the thread should be breakpoint.
+self.expect(
+"thread list",
+STOPPED_DUE_TO_BREAKPOINT,
+substrs=['stopped', 'stop reason = breakpoint'])
+
+# This is the function to remove the custom formats in order to have a
+# clean slate for the next test case.
+def cleanup():
+self.runCmd('type format clear', check=False)
+self.runCmd('type summary clear', check=False)
+self.runCmd('type synth clear', check=False)
+
+# Execute the cleanup function during test case tear down.
+self.addTearDownHook(cleanup)
+
+# as long as KVO is implemented by subclassing, this test should succeed
+# we should be able to dynamically figure out that the KVO implementor class
+# is a subclass of Molecule, and use the appropriate summary for it
+self.runCmd("type summary add -s JustAMoleculeHere Molecule")
+self.expect('frame variable molecule', substrs=['JustAMoleculeHere'])
+self.runCmd("next")
+self.expect("thread list", substrs=['stopped', 'step over'])
+self.expect('frame variable molecule', substrs=['JustAMoleculeHere'])
+
+self.runCmd("next")
+# check that NSMutableDictionary's formatter is not confused when
+# dealing with a KVO'd dictionary
+self.expect(
+'frame variable newMutableDictionary',
+substrs=[
+'(NSDictionary *) newMutableDictionary = ',
+ 

[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added a comment.

> What's the motivation behind all the `@no_debug_info_test` decorators? Are 
> those codepaths guaranteed to be tested elsewhere?

As a rule of thumb I'd say, let's only stick `@no_debug_info_test` on tests 
where a (future) coverage bot proves that it is safe. How does that sound?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

In D60300#1456485 , @aprantl wrote:

> > What's the motivation behind all the `@no_debug_info_test` decorators? Are 
> > those codepaths guaranteed to be tested elsewhere?
>
> As a rule of thumb I'd say, let's only stick `@no_debug_info_test` on tests 
> where a (future) coverage bot proves that it is safe. How does that sound?


Sounds good, I'll remove the decorators and we can do this incrementally.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Davide Italiano via Phabricator via lldb-commits
davide added a comment.

In D60300#1456472 , @clayborg wrote:

> In D60300#1456468 , @JDevlieghere 
> wrote:
>
> > In D60300#1455790 , @davide wrote:
> >
> > > I think this is good regardless for readability, but I would really 
> > > appreciate if we can collect some numbers to see how effective this 
> > > change actually is.
> >
> >
> > I see 120 -> 12 seconds on my iMac Pro.
>
>
> Nice! Might be nice to have some automated info that gets dumped when one 
> file with multiple tests takes a long time and suggest breaking them up in 
> the python test infrastructure modules. Might be other nice gains to be had?


lit has this feature. It's called `--time-tests`. That's how we discovered the 
problem. There are other tests that we can fix.

--Davide


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60300: [testsuite] Split Objective-C data formatter

2019-04-05 Thread Davide Italiano via Phabricator via lldb-commits
davide added a comment.

In D60300#1456491 , @davide wrote:

> In D60300#1456472 , @clayborg wrote:
>
> > In D60300#1456468 , @JDevlieghere 
> > wrote:
> >
> > > In D60300#1455790 , @davide 
> > > wrote:
> > >
> > > > I think this is good regardless for readability, but I would really 
> > > > appreciate if we can collect some numbers to see how effective this 
> > > > change actually is.
> > >
> > >
> > > I see 120 -> 12 seconds on my iMac Pro.
> >
> >
> > Nice! Might be nice to have some automated info that gets dumped when one 
> > file with multiple tests takes a long time and suggest breaking them up in 
> > the python test infrastructure modules. Might be other nice gains to be had?
>
>
> lit has this feature. It's called `--time-tests`. That's how we discovered 
> the problem. There are other tests that we can fix.
>
> --Davide


And, as you ask, these are the slowest tests for now.

  68.25s: lldb-Suite :: types/TestIntegerTypes.py
  86.52s: lldb-Suite :: types/TestIntegerTypesExpr.py
  95.66s: lldb-Suite :: lang/objc/foundation/TestObjCMethods2.py
  131.24s: lldb-Suite :: lang/objc/objc-new-syntax/TestObjCNewSyntax.py


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60300



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


[Lldb-commits] [PATCH] D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds

2019-04-05 Thread Alex Langford via Phabricator via lldb-commits
xiaobai added a comment.

In D60180#1456263 , @sgraenitz wrote:

> > No, everything is being built for android. Cross-compiling lldb-server 
> > involves cross-compiling llvm libraries, clang libraries, and if you've got 
> > swift in the picture, swift host libraries. LLVM and clang libraries are 
> > built against the libc++ from the android NDK, but in standalone builds, 
> > LLDB will try to link against the freshly built libc++ from LLVM. You get 
> > loads of undefined references to symbols from the NDK's libc++.
>
> For the `link_directories` line: if you cross-compile the entire tree and 
> this tree contains libc++, wouldn't it be natural that LLDB will try to link 
> against the freshly built libc++?
>  If this is not your intention, then maybe we need a `LLDB_EXTERNAL_LIBCXX` 
> option instead?


I don't agree that this is the natural thing to do. From my perspective, you 
should be using the same sysroot to build LLVM and LLDB. In my specific 
problem, when you build any of the lldb tools (e.g. lldb-server) it fails to 
link because you are building the tool against the freshly built libc++ but the 
llvm libraries you had previously built were linked against the NDK's libc++.

In D60180#1456239 , @sgraenitz wrote:

> > If there's a situation where any of these variables don't get propagated 
> > from the LLVMConfig, I'd like to know about it so I can add comments above 
> > these variables explaining why these variables are set since it's 
> > non-obvious just from grepping the lldb tree.
>
> It's usually a good idea to check both, the LLVMConfig.cmake from a 
> build-tree and from an install-tree. They are quite different and LLDB 
> standalone should work with both.
>
> You can check the green dragon bot that we added recently: 
> http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/
>  It builds against both versions (and BTW it also dumps CMake cache entries).


Ooh, I like this bot. Thanks for pointing it out!


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

https://reviews.llvm.org/D60180



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


[Lldb-commits] [PATCH] D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds

2019-04-05 Thread Stefan Gränitz via Phabricator via lldb-commits
sgraenitz accepted this revision.
sgraenitz added a comment.
This revision is now accepted and ready to land.

> you should be using the same sysroot to build LLVM and LLDB. In my specific 
> problem, when you build any of the lldb tools (e.g. lldb-server) it fails to 
> link because you are building the tool against the freshly built libc++ but 
> the llvm libraries you had previously built were linked against the NDK's 
> libc++.

Ok agreed.

clang and lld do the same and/but it's old code (3+ years). Well, hope it's 
well tested. Please keep an eye on the bots.


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

https://reviews.llvm.org/D60180



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


[Lldb-commits] [lldb] r357813 - [Test] Remove no_debug_info_test decorator from Obj-C data formatters.

2019-04-05 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Fri Apr  5 13:37:52 2019
New Revision: 357813

URL: http://llvm.org/viewvc/llvm-project?rev=357813&view=rev
Log:
[Test] Remove no_debug_info_test decorator from Obj-C data formatters.

As discussed in https://reviews.llvm.org/D60300.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCExpr.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSData.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSError.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSURL.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCPlain.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjNSException.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py?rev=357813&r1=357812&r2=357813&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCCF.py
 Fri Apr  5 13:37:52 2019
@@ -16,7 +16,6 @@ from ObjCDataFormatterTestCase import Ob
 class ObjCDataFormatterCF(ObjCDataFormatterTestCase):
 
 @skipUnlessDarwin
-@no_debug_info_test
 def test_coreframeworks_and_run_command(self):
 """Test formatters for Core OSX frameworks."""
 self.build()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCExpr.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCExpr.py?rev=357813&r1=357812&r2=357813&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCExpr.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCExpr.py
 Fri Apr  5 13:37:52 2019
@@ -16,7 +16,6 @@ from ObjCDataFormatterTestCase import Ob
 class ObjCDataFormatterExpr(ObjCDataFormatterTestCase):
 
 @skipUnlessDarwin
-@no_debug_info_test
 def test_expr_with_run_command(self):
 """Test common cases of expression parser <--> formatters 
interaction."""
 self.build()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py?rev=357813&r1=357812&r2=357813&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCKVO.py
 Fri Apr  5 13:37:52 2019
@@ -16,7 +16,6 @@ from ObjCDataFormatterTestCase import Ob
 class ObjCDataFormatterKVO(ObjCDataFormatterTestCase):
 
 @skipUnlessDarwin
-@no_debug_info_test
 def test_kvo_with_run_command(self):
 """Test the behavior of formatters when KVO is in use."""
 self.build()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSBundle.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFor

[Lldb-commits] [lldb] r357817 - [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds

2019-04-05 Thread Alex Langford via lldb-commits
Author: xiaobai
Date: Fri Apr  5 14:01:50 2019
New Revision: 357817

URL: http://llvm.org/viewvc/llvm-project?rev=357817&view=rev
Log:
[CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds

Summary:
This line is unnecessary because add_llvm_executable will handle
linking the correct LLVM libraries for you. LLDB standalone builds are totally
fine without this.

In the best case, having this line here is harmless. In the worst case it can
cause link issues.

If you build lldb-server for android using the standalone build, this line
will cause LLVM_LIBRARY_DIR to be the first place you look for libraries.
This is an issue because if you built libc++, it will try to link against
that one instead of the one from the android NDK.  Meanwhile, the LLVM libraries
you're linking against were linked against the libc++ from the NDK.

Ideally, we would take advantage of the AFTER option for link_directories(), but
that was not available in LLDB's minimum supported version of CMake (CMake 
3.4.3).

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

Modified:
lldb/trunk/cmake/modules/LLDBStandalone.cmake

Modified: lldb/trunk/cmake/modules/LLDBStandalone.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBStandalone.cmake?rev=357817&r1=357816&r2=357817&view=diff
==
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake Fri Apr  5 14:01:50 2019
@@ -21,7 +21,6 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
 
   set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM 
source tree")
   set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to 
llvm/include")
-  set(LLVM_LIBRARY_DIR ${LLVM_LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
   set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
 
   set(lit_file_name "llvm-lit")
@@ -95,8 +94,6 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
 "${LLVM_INCLUDE_DIRS}"
 "${CLANG_INCLUDE_DIRS}")
 
-  link_directories("${LLVM_LIBRARY_DIR}")
-
   set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
   set(CMAKE_LIBRARY_OUTPUT_DIRECTORY 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
   set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})


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


[Lldb-commits] [PATCH] D60180: [CMake] Don't explicitly use LLVM_LIBRARY_DIR in standalone builds

2019-04-05 Thread Alex Langford via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB357817: [CMake] Don't explicitly use 
LLVM_LIBRARY_DIR in standalone builds (authored by xiaobai, committed by ).
Herald added a subscriber: abidh.
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D60180?vs=193436&id=193965#toc

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60180

Files:
  cmake/modules/LLDBStandalone.cmake


Index: cmake/modules/LLDBStandalone.cmake
===
--- cmake/modules/LLDBStandalone.cmake
+++ cmake/modules/LLDBStandalone.cmake
@@ -21,7 +21,6 @@
 
   set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM 
source tree")
   set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to 
llvm/include")
-  set(LLVM_LIBRARY_DIR ${LLVM_LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
   set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
 
   set(lit_file_name "llvm-lit")
@@ -95,8 +94,6 @@
 "${LLVM_INCLUDE_DIRS}"
 "${CLANG_INCLUDE_DIRS}")
 
-  link_directories("${LLVM_LIBRARY_DIR}")
-
   set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
   set(CMAKE_LIBRARY_OUTPUT_DIRECTORY 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
   set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})


Index: cmake/modules/LLDBStandalone.cmake
===
--- cmake/modules/LLDBStandalone.cmake
+++ cmake/modules/LLDBStandalone.cmake
@@ -21,7 +21,6 @@
 
   set(LLVM_MAIN_SRC_DIR ${LLVM_BUILD_MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
   set(LLVM_MAIN_INCLUDE_DIR ${LLVM_MAIN_INCLUDE_DIR} CACHE PATH "Path to llvm/include")
-  set(LLVM_LIBRARY_DIR ${LLVM_LIBRARY_DIR} CACHE PATH "Path to llvm/lib")
   set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR} CACHE PATH "Path to LLVM build tree")
 
   set(lit_file_name "llvm-lit")
@@ -95,8 +94,6 @@
 "${LLVM_INCLUDE_DIRS}"
 "${CLANG_INCLUDE_DIRS}")
 
-  link_directories("${LLVM_LIBRARY_DIR}")
-
   set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
   set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
   set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX})
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D60340: Unify random timeouts throughout LLDB and make them configurable.

2019-04-05 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl created this revision.
aprantl added a reviewer: jingham.
Herald added subscribers: kubamracek, emaste.
Herald added a project: LLDB.

Since these timeouts guard against catastrophic error in debugserver, I also 
increased all of them to the maximum value among them.

The motivation for this test was the observation that an asanified LLDB would 
often exhibit seemingly random test failures that could be traced back to 
debugserver packets getting out of sync. With this path applied I can no longer 
reproduce the one particular failure mode that I was investigating.

rdar://problem/49441261


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D60340

Files:
  lldb/include/lldb/Target/Process.h
  lldb/source/Plugins/InstrumentationRuntime/ASan/ASanRuntime.cpp
  lldb/source/Plugins/InstrumentationRuntime/TSan/TSanRuntime.cpp
  lldb/source/Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.cpp
  
lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
  lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
  lldb/source/Plugins/MemoryHistory/asan/MemoryHistoryASan.cpp
  lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
  lldb/source/Target/Process.cpp

Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -144,7 +144,11 @@
  "stepping and variable availability may not behave as expected."},
 {"stop-on-exec", OptionValue::eTypeBoolean, true, true,
  nullptr, {},
- "If true, stop when a shared library is loaded or unloaded."}};
+ "If true, stop when a shared library is loaded or unloaded."},
+{"debugserver-timeout", OptionValue::eTypeUInt64, false, 15,
+ nullptr, {},
+ "The time in seconds to wait for a response from debugserver."}
+};
 
 enum {
   ePropertyDisableMemCache,
@@ -156,7 +160,8 @@
   ePropertyDetachKeepsStopped,
   ePropertyMemCacheLineSize,
   ePropertyWarningOptimization,
-  ePropertyStopOnExec
+  ePropertyStopOnExec,
+  ePropertyDebugserverResponseTimeout,
 };
 
 ProcessProperties::ProcessProperties(lldb_private::Process *process)
@@ -279,6 +284,13 @@
   nullptr, idx, g_properties[idx].default_uint_value != 0);
 }
 
+std::chrono::seconds ProcessProperties::GetDebugserverResponseTimeout() const {
+  const uint32_t idx = ePropertyDebugserverResponseTimeout;
+  uint64_t value = m_collection_sp->GetPropertyAtIndexAsUInt64(
+ nullptr, idx, g_properties[idx].default_uint_value);
+  return std::chrono::seconds(value);
+}
+
 Status ProcessLaunchCommandOptions::SetOptionValue(
 uint32_t option_idx, llvm::StringRef option_arg,
 ExecutionContext *execution_context) {
Index: lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
@@ -344,7 +344,7 @@
   options.SetUnwindOnError(true);
   options.SetIgnoreBreakpoints(true);
   options.SetStopOthers(true);
-  options.SetTimeout(std::chrono::milliseconds(500));
+  options.SetTimeout(process_sp->GetDebugserverResponseTimeout());
   options.SetTryAllThreads(false);
   options.SetIsForUtilityExpr(true);
   thread.CalculateExecutionContext(exe_ctx);
Index: lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
@@ -347,7 +347,7 @@
   options.SetUnwindOnError(true);
   options.SetIgnoreBreakpoints(true);
   options.SetStopOthers(true);
-  options.SetTimeout(std::chrono::milliseconds(500));
+  options.SetTimeout(process_sp->GetDebugserverResponseTimeout());
   options.SetTryAllThreads(false);
   options.SetIsForUtilityExpr(true);
   thread.CalculateExecutionContext(exe_ctx);
Index: lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
@@ -342,7 +342,7 @@
   options.SetUnwindOnError(true);
   options.SetIgnoreBreakpoints(true);
   optio

[Lldb-commits] [PATCH] D60340: Unify random timeouts throughout LLDB and make them configurable.

2019-04-05 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added a comment.

I should also note that I did check that process was either checked or 
dereferenced above the the locations where this patch dereferences it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60340



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


[Lldb-commits] [PATCH] D60340: Unify random timeouts throughout LLDB and make them configurable.

2019-04-05 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl updated this revision to Diff 193975.
aprantl added a comment.

Tweaked the name of the option after some off-line discussion with Jim.


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

https://reviews.llvm.org/D60340

Files:
  lldb/include/lldb/Target/Process.h
  lldb/source/Plugins/InstrumentationRuntime/ASan/ASanRuntime.cpp
  lldb/source/Plugins/InstrumentationRuntime/TSan/TSanRuntime.cpp
  lldb/source/Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.cpp
  
lldb/source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
  lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
  lldb/source/Plugins/MemoryHistory/asan/MemoryHistoryASan.cpp
  lldb/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
  lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
  lldb/source/Target/Process.cpp

Index: lldb/source/Target/Process.cpp
===
--- lldb/source/Target/Process.cpp
+++ lldb/source/Target/Process.cpp
@@ -144,7 +144,11 @@
  "stepping and variable availability may not behave as expected."},
 {"stop-on-exec", OptionValue::eTypeBoolean, true, true,
  nullptr, {},
- "If true, stop when a shared library is loaded or unloaded."}};
+ "If true, stop when a shared library is loaded or unloaded."},
+{"utility-expression-timeout", OptionValue::eTypeUInt64, false, 15,
+ nullptr, {},
+ "The time in seconds to wait for LLDB-internal utility expressions."}
+};
 
 enum {
   ePropertyDisableMemCache,
@@ -156,7 +160,8 @@
   ePropertyDetachKeepsStopped,
   ePropertyMemCacheLineSize,
   ePropertyWarningOptimization,
-  ePropertyStopOnExec
+  ePropertyStopOnExec,
+  ePropertyUtilityExpressionTimeout,
 };
 
 ProcessProperties::ProcessProperties(lldb_private::Process *process)
@@ -279,6 +284,13 @@
   nullptr, idx, g_properties[idx].default_uint_value != 0);
 }
 
+std::chrono::seconds ProcessProperties::GetUtilityExpressionTimeout() const {
+  const uint32_t idx = ePropertyUtilityExpressionTimeout;
+  uint64_t value = m_collection_sp->GetPropertyAtIndexAsUInt64(
+ nullptr, idx, g_properties[idx].default_uint_value);
+  return std::chrono::seconds(value);
+}
+
 Status ProcessLaunchCommandOptions::SetOptionValue(
 uint32_t option_idx, llvm::StringRef option_arg,
 ExecutionContext *execution_context) {
@@ -3606,10 +3618,10 @@
 bool receipt_received = false;
 if (PrivateStateThreadIsValid()) {
   while (!receipt_received) {
-// Check for a receipt for 2 seconds and then check if the private
+// Check for a receipt for n seconds and then check if the private
 // state thread is still around.
 receipt_received =
-event_receipt_sp->WaitForEventReceived(std::chrono::seconds(2));
+  event_receipt_sp->WaitForEventReceived(GetUtilityExpressionTimeout());
 if (!receipt_received) {
   // Check if the private state thread is still around. If it isn't
   // then we are done waiting
@@ -4902,7 +4914,7 @@
 }
 
 got_event =
-listener_sp->GetEvent(event_sp, std::chrono::milliseconds(500));
+listener_sp->GetEvent(event_sp, GetUtilityExpressionTimeout());
 if (!got_event) {
   if (log)
 log->Printf("Process::RunThreadPlan(): didn't get any event after "
@@ -5133,7 +5145,7 @@
   log->PutCString("Process::RunThreadPlan(): Halt succeeded.");
 
 got_event =
-listener_sp->GetEvent(event_sp, std::chrono::milliseconds(500));
+listener_sp->GetEvent(event_sp, GetUtilityExpressionTimeout());
 
 if (got_event) {
   stop_state =
Index: lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
===
--- lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
+++ lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
@@ -344,7 +344,7 @@
   options.SetUnwindOnError(true);
   options.SetIgnoreBreakpoints(true);
   options.SetStopOthers(true);
-  options.SetTimeout(std::chrono::milliseconds(500));
+  options.SetTimeout(process_sp->GetUtilityExpressionTimeout());
   options.SetTryAllThreads(false);
   options.SetIsForUtilityExpr(true);
   thread.CalculateExecutionContext(exe_ctx);
Index: lldb/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
=

[Lldb-commits] [lldb] r357824 - [testsuite] Split Objective-C new syntax test

2019-04-05 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Fri Apr  5 15:06:53 2019
New Revision: 357824

URL: http://llvm.org/viewvc/llvm-project?rev=357824&view=rev
Log:
[testsuite] Split Objective-C new syntax test

This splits the second longest test into separate test cases. Similar to
what we did for the Objective-C data formatters in r357786.

Added:

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/ObjCNewSyntaxTest.py

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntaxArray.py

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntaxDictionary.py

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntaxLiteral.py
Removed:

lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py

Added: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/ObjCNewSyntaxTest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/ObjCNewSyntaxTest.py?rev=357824&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/ObjCNewSyntaxTest.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/ObjCNewSyntaxTest.py
 Fri Apr  5 15:06:53 2019
@@ -0,0 +1,29 @@
+"""Test that the Objective-C syntax for dictionary/array literals and indexing 
works"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class ObjCNewSyntaxTest(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def runToBreakpoint(self):
+self.build()
+self.target, process, thread, bkpt = lldbutil.run_to_source_breakpoint(
+self, '// Set breakpoint 0 here.', lldb.SBFileSpec(
+'main.m', False))
+
+# The stop reason of the thread should be breakpoint.
+self.expect(
+"thread list",
+STOPPED_DUE_TO_BREAKPOINT,
+substrs=['stopped', 'stop reason = breakpoint'])
+
+# The breakpoint should have a hit count of 1.
+self.expect(
+"breakpoint list -f",
+BREAKPOINT_HIT_ONCE,
+substrs=[' resolved, hit count = 1'])

Removed: 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py?rev=357823&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/objc/objc-new-syntax/TestObjCNewSyntax.py
 (removed)
@@ -1,204 +0,0 @@
-"""Test that the Objective-C syntax for dictionary/array literals and indexing 
works"""
-
-from __future__ import print_function
-
-
-import unittest2
-import os
-import time
-import platform
-
-from distutils.version import StrictVersion
-
-import lldb
-from lldbsuite.test.decorators import *
-from lldbsuite.test.lldbtest import *
-from lldbsuite.test import lldbutil
-
-
-class ObjCNewSyntaxTestCase(TestBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-def setUp(self):
-# Call super's setUp().
-TestBase.setUp(self)
-# Find the line number to break inside main().
-self.line = line_number('main.m', '// Set breakpoint 0 here.')
-
-def runToBreakpoint(self):
-self.build()
-exe = self.getBuildArtifact("a.out")
-self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
-
-# Break inside the foo function which takes a bar_ptr argument.
-lldbutil.run_break_set_by_file_and_line(
-self, "main.m", self.line, num_expected_locations=1, 
loc_exact=True)
-
-self.runCmd("run", RUN_SUCCEEDED)
-
-# The stop reason of the thread should be breakpoint.
-self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
-substrs=['stopped',
- 'stop reason = breakpoint'])
-
-# The breakpoint should have a hit count of 1.
-self.expect("breakpoint list -f", BREAKPOINT_HIT_ONCE,
-substrs=[' resolved, hit count = 1'])
-
-@skipUnlessDarwin
-@skipIf(macos_version=["<", "10.12"])
-@expectedFailureAll(archs=["i[3-6]86"])
-def test_read_array(self):
-self.runToBreakpoint()
-
-self.expect(
-"expr --object-description -- immutable_array[0]",
-VARIABLES_DISPLAYED_CORRECTLY,
-substrs=["foo"])
-
-self.expect(
-"expr --object-description -- mutable_array[0]",
-VARIABLES_DISPLAYED_CORRECTLY,
-substrs=["foo"])
-
-@skipUnlessDarwin
-@skipIf(macos_version=["<", "10.12"])
-@

[Lldb-commits] [PATCH] D60340: Unify random timeouts throughout LLDB and make them configurable.

2019-04-05 Thread Jim Ingham via Phabricator via lldb-commits
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D60340



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


[Lldb-commits] [lldb] r357829 - Unify random timeouts throughout LLDB and make them configurable.

2019-04-05 Thread Adrian Prantl via lldb-commits
Author: adrian
Date: Fri Apr  5 15:43:42 2019
New Revision: 357829

URL: http://llvm.org/viewvc/llvm-project?rev=357829&view=rev
Log:
Unify random timeouts throughout LLDB and make them configurable.

Since these timeouts guard against catastrophic error in debugserver,
I also increased all of them to the maximum value among them.

The motivation for this test was the observation that an asanified
LLDB would often exhibit seemingly random test failures that could be
traced back to debugserver packets getting out of sync. With this path
applied I can no longer reproduce the one particular failure mode that
I was investigating.

rdar://problem/49441261

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

Modified:
lldb/trunk/include/lldb/Target/Process.h
lldb/trunk/source/Plugins/InstrumentationRuntime/ASan/ASanRuntime.cpp
lldb/trunk/source/Plugins/InstrumentationRuntime/TSan/TSanRuntime.cpp
lldb/trunk/source/Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.cpp

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

lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp

lldb/trunk/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
lldb/trunk/source/Plugins/MemoryHistory/asan/MemoryHistoryASan.cpp
lldb/trunk/source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
lldb/trunk/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp
lldb/trunk/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp

lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp

lldb/trunk/source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
lldb/trunk/source/Target/Process.cpp

Modified: lldb/trunk/include/lldb/Target/Process.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Process.h?rev=357829&r1=357828&r2=357829&view=diff
==
--- lldb/trunk/include/lldb/Target/Process.h (original)
+++ lldb/trunk/include/lldb/Target/Process.h Fri Apr  5 15:43:42 2019
@@ -68,36 +68,22 @@ public:
   ~ProcessProperties() override;
 
   bool GetDisableMemoryCache() const;
-
   uint64_t GetMemoryCacheLineSize() const;
-
   Args GetExtraStartupCommands() const;
-
   void SetExtraStartupCommands(const Args &args);
-
   FileSpec GetPythonOSPluginPath() const;
-
   void SetPythonOSPluginPath(const FileSpec &file);
-
   bool GetIgnoreBreakpointsInExpressions() const;
-
   void SetIgnoreBreakpointsInExpressions(bool ignore);
-
   bool GetUnwindOnErrorInExpressions() const;
-
   void SetUnwindOnErrorInExpressions(bool ignore);
-
   bool GetStopOnSharedLibraryEvents() const;
-
   void SetStopOnSharedLibraryEvents(bool stop);
-
   bool GetDetachKeepsStopped() const;
-
   void SetDetachKeepsStopped(bool keep_stopped);
-
   bool GetWarningsOptimization() const;
-
   bool GetStopOnExec() const;
+  std::chrono::seconds GetUtilityExpressionTimeout() const;
 
 protected:
   static void OptionValueChangedCallback(void *baton,

Modified: lldb/trunk/source/Plugins/InstrumentationRuntime/ASan/ASanRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/InstrumentationRuntime/ASan/ASanRuntime.cpp?rev=357829&r1=357828&r2=357829&view=diff
==
--- lldb/trunk/source/Plugins/InstrumentationRuntime/ASan/ASanRuntime.cpp 
(original)
+++ lldb/trunk/source/Plugins/InstrumentationRuntime/ASan/ASanRuntime.cpp Fri 
Apr  5 15:43:42 2019
@@ -71,7 +71,6 @@ bool AddressSanitizerRuntime::CheckIfRun
   return symbol != nullptr;
 }
 
-static constexpr std::chrono::seconds 
g_retrieve_report_data_function_timeout(2);
 const char *address_sanitizer_retrieve_report_data_prefix = R"(
 extern "C"
 {
@@ -126,7 +125,7 @@ StructuredData::ObjectSP AddressSanitize
   options.SetTryAllThreads(true);
   options.SetStopOthers(true);
   options.SetIgnoreBreakpoints(true);
-  options.SetTimeout(g_retrieve_report_data_function_timeout);
+  options.SetTimeout(process_sp->GetUtilityExpressionTimeout());
   options.SetPrefix(address_sanitizer_retrieve_report_data_prefix);
   options.SetAutoApplyFixIts(false);
   options.SetLanguage(eLanguageTypeObjC_plus_plus);

Modified: lldb/trunk/source/Plugins/InstrumentationRuntime/TSan/TSanRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/InstrumentationRuntime/TSan/TSanRuntime.cpp?rev=357829&r1=357828&r2=357829&view=diff
==
--- lldb/trunk/source/Plugins/InstrumentationRuntime/TSan/TSanRuntime.cpp 
(original)
+++ lldb/trunk/source/Plugins/InstrumentationRuntime/TSan/TSanRuntime.cpp Fri 
Apr  5 15:43:42 2019
@@ -60,8 +60,6 @@ lldb::Instrumenta

[Lldb-commits] [PATCH] D60340: Unify random timeouts throughout LLDB and make them configurable.

2019-04-05 Thread Phabricator via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB357829: Unify random timeouts throughout LLDB and make 
them configurable. (authored by adrian, committed by ).
Herald added a subscriber: abidh.

Changed prior to commit:
  https://reviews.llvm.org/D60340?vs=193975&id=193980#toc

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60340

Files:
  include/lldb/Target/Process.h
  source/Plugins/InstrumentationRuntime/ASan/ASanRuntime.cpp
  source/Plugins/InstrumentationRuntime/TSan/TSanRuntime.cpp
  source/Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.cpp
  
source/Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.cpp
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.cpp
  source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
  source/Plugins/MemoryHistory/asan/MemoryHistoryASan.cpp
  source/Plugins/Platform/POSIX/PlatformPOSIX.cpp
  source/Plugins/Process/Utility/InferiorCallPOSIX.cpp
  source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetPendingItemsHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetQueuesHandler.cpp
  source/Plugins/SystemRuntime/MacOSX/AppleGetThreadItemInfoHandler.cpp
  source/Target/Process.cpp

Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -144,7 +144,11 @@
  "stepping and variable availability may not behave as expected."},
 {"stop-on-exec", OptionValue::eTypeBoolean, true, true,
  nullptr, {},
- "If true, stop when a shared library is loaded or unloaded."}};
+ "If true, stop when a shared library is loaded or unloaded."},
+{"utility-expression-timeout", OptionValue::eTypeUInt64, false, 15,
+ nullptr, {},
+ "The time in seconds to wait for LLDB-internal utility expressions."}
+};
 
 enum {
   ePropertyDisableMemCache,
@@ -156,7 +160,8 @@
   ePropertyDetachKeepsStopped,
   ePropertyMemCacheLineSize,
   ePropertyWarningOptimization,
-  ePropertyStopOnExec
+  ePropertyStopOnExec,
+  ePropertyUtilityExpressionTimeout,
 };
 
 ProcessProperties::ProcessProperties(lldb_private::Process *process)
@@ -279,6 +284,13 @@
   nullptr, idx, g_properties[idx].default_uint_value != 0);
 }
 
+std::chrono::seconds ProcessProperties::GetUtilityExpressionTimeout() const {
+  const uint32_t idx = ePropertyUtilityExpressionTimeout;
+  uint64_t value = m_collection_sp->GetPropertyAtIndexAsUInt64(
+ nullptr, idx, g_properties[idx].default_uint_value);
+  return std::chrono::seconds(value);
+}
+
 Status ProcessLaunchCommandOptions::SetOptionValue(
 uint32_t option_idx, llvm::StringRef option_arg,
 ExecutionContext *execution_context) {
@@ -3606,10 +3618,10 @@
 bool receipt_received = false;
 if (PrivateStateThreadIsValid()) {
   while (!receipt_received) {
-// Check for a receipt for 2 seconds and then check if the private
+// Check for a receipt for n seconds and then check if the private
 // state thread is still around.
 receipt_received =
-event_receipt_sp->WaitForEventReceived(std::chrono::seconds(2));
+  event_receipt_sp->WaitForEventReceived(GetUtilityExpressionTimeout());
 if (!receipt_received) {
   // Check if the private state thread is still around. If it isn't
   // then we are done waiting
@@ -4902,7 +4914,7 @@
 }
 
 got_event =
-listener_sp->GetEvent(event_sp, std::chrono::milliseconds(500));
+listener_sp->GetEvent(event_sp, GetUtilityExpressionTimeout());
 if (!got_event) {
   if (log)
 log->Printf("Process::RunThreadPlan(): didn't get any event after "
@@ -5133,7 +5145,7 @@
   log->PutCString("Process::RunThreadPlan(): Halt succeeded.");
 
 got_event =
-listener_sp->GetEvent(event_sp, std::chrono::milliseconds(500));
+listener_sp->GetEvent(event_sp, GetUtilityExpressionTimeout());
 
 if (got_event) {
   stop_state =
Index: source/Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.cpp
===
--- source/Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.cpp
+++ source/Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.cpp
@@ -131,7 +131,7 @@
   options.SetTryAllThreads(true);
   options.SetStopOthers(true);
   options.SetIgnoreBreakpoints(true);
-  options.SetTimeout(std::chrono::seconds(2));
+  options.SetTimeout(process_sp->GetUtilityExpressionTimeout());
   options.SetPrefix(ub_sanitizer_retrieve_report_data_prefix);
   options.SetAutoApplyFixIts(false);
   options.SetLanguage(eLanguageTypeObjC_plus_plus);
Index: source/Plugins/Instrumentat

[Lldb-commits] [PATCH] D60172: Renamed Target::GetSharedModule to AddModule, allow for ModulesDidLoad to be delayed when batch adding Modules

2019-04-05 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda updated this revision to Diff 194000.
jasonmolenda added a comment.

Added a testcase, TestModuleLoadedNotifys.

Renamed the pure virtual notifier methods in ModuleList to add 'Notify' at the 
start of their names, updated the names in subclass Target as well.  Added a 
NotifyModulesRemoved and changed ModuleList::Remove(ModuleList&) so that it 
removes all of the modules one-by-one from the collection and then calls 
NotifyModulesRemoved() so they are broadcast as a group.  I renamed the methods 
to make it clearer in Target that these are subclass implementations.

Changed Target::SetExecutableModule() so that it will load all dependent 
libraries without notifying, and send a group notification about all of them 
once they've been added.

Moved the call to LoadScriptingResourceForModule from Target::NotifyModuleAdded 
to Target::ModulesDidLoad so DynamicLoader plugins can call ModulesDidLoad with 
the full list of libraries and still get scripting files loaded.

I tried changing Target::GetOrCreateModule to return Expected but I 
wasn't thrilled with the double-dereference of the returned value when I 
started updating callers.  It wasn't horrible, but it looked messy.  I should 
go back and try again but my first shot at a few of them didn't look great.

I want to hand-test the scripting resource loading a bit on Monday but this is 
probably about what I'm doing for now.  At this point, DynamicLoaderDarwin 
sends batched notifications on the CreateTarget() binary dependent binaries.  
It sends a batched notification when we start a real process and throw away all 
those binaries.  It sends out batched notifications when we load the binaries 
back in via dyld notifications.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D60172

Files:
  include/lldb/Core/ModuleList.h
  include/lldb/Target/Target.h
  
packages/Python/lldbsuite/test/functionalities/target-new-solib-notifications/Makefile
  
packages/Python/lldbsuite/test/functionalities/target-new-solib-notifications/TestModuleLoadedNotifys.py
  
packages/Python/lldbsuite/test/functionalities/target-new-solib-notifications/main.cpp
  source/API/SBTarget.cpp
  source/Commands/CommandObjectTarget.cpp
  source/Core/DynamicLoader.cpp
  source/Core/ModuleList.cpp
  source/Expression/FunctionCaller.cpp
  source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
  source/Plugins/DynamicLoader/Hexagon-DYLD/DynamicLoaderHexagonDYLD.cpp
  source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
  source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
  source/Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.cpp
  source/Plugins/Process/Windows/Common/ProcessWindows.cpp
  source/Plugins/Process/elf-core/ProcessElfCore.cpp
  source/Plugins/Process/minidump/ProcessMinidump.cpp
  source/Target/Target.cpp

Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -1442,7 +1442,8 @@
"Target::SetExecutableModule (executable = '%s')",
executable_sp->GetFileSpec().GetPath().c_str());
 
-m_images.Append(executable_sp); // The first image is our executable file
+const bool notify = true;
+m_images.Append(executable_sp, notify); // The first image is our executable file
 
 // If we haven't set an architecture yet, reset our architecture based on
 // what we found in the executable module.
@@ -1470,6 +1471,7 @@
 }
 
 if (executable_objfile && load_dependents) {
+  ModuleList added_modules;
   executable_objfile->GetDependentModules(dependent_files);
   for (uint32_t i = 0; i < dependent_files.GetSize(); i++) {
 FileSpec dependent_file_spec(
@@ -1482,13 +1484,16 @@
   platform_dependent_file_spec = dependent_file_spec;
 
 ModuleSpec module_spec(platform_dependent_file_spec, m_arch.GetSpec());
-ModuleSP image_module_sp(GetSharedModule(module_spec));
+ModuleSP image_module_sp(GetOrCreateModule(module_spec, 
+ false /* notify */));
 if (image_module_sp) {
+  added_modules.AppendIfNeeded (image_module_sp, false);
   ObjectFile *objfile = image_module_sp->GetObjectFile();
   if (objfile)
 objfile->GetDependentModules(dependent_files);
 }
   }
+  ModulesDidLoad(added_modules);
 }
   }
 }
@@ -1606,20 +1611,19 @@
   return false;
 }
 
-void Target::WillClearList(const ModuleList &module_list) {}
+void Target::NotifyWillClearList(const ModuleList &module_list) {}
 
-void Target::ModuleAdded(const ModuleList &module_list,
+void Target::NotifyModuleAdded(const ModuleList &module_list,
  const ModuleSP &module_sp) {
   // A module is being added to this target for the first time
   if (m_valid) {
 ModuleList my_mo