Re: [Lldb-commits] [lldb] r339178 - [lldb-mi] Re-implement target-select command

2018-08-09 Thread Tim Northover via lldb-commits 
Hi,

I think this is causing the lldb-cmake test to hang on Green Dragon.
The build revision numbers don't exactly match up for reasons I don't
quite understand, but when I locally run check-lldb this is the test
that spins for ages, and reverting this change doesn't move the
timeout elsewhere.

I think the root of the issue is that macOS's debugserver has a very
different command-line interface from lldb-server, it bails and that
causes the pipe read to hang. But there seem to be other issues when I
try to run it manually too:

tim@timn ~/llvm/llvm-project/lldb $
/opt/local/Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
/Users/tim/llvm/llvm-project/lldb/lit/tools/lldb-mi/target/inputs/target-select-so-path.py
/Users/tim/llvm/build.lldb/bin/debugserver
/Users/tim/llvm/build.lldb/bin/lldb-mi --synchronous
/Users/tim/llvm/build.lldb/tools/lldb/lit/tools/lldb-mi/target/Output/target-select-so-path.test.tmp
/Users/tim/llvm/llvm-project/lldb/lit/tools/lldb-mi/target/target-select-so-path.test
FileCheck: Unknown command line argument '--synchronous'.  Try:
'FileCheck -help'
FileCheck: Did you mean '-version'?
FileCheck: Not enough positional command line arguments specified!
Must specify at least 1 positional argument: See: FileCheck -help
debugserver: unrecognized option `--pipe'
debugserver-@(#)PROGRAM:LLDB  PROJECT:lldb-360.99.0
 for x86_64.
error: failed to launch process
/Users/tim/llvm/build.lldb/bin/debugserver: No such file or directory
(localhost:0)
Exiting.

(It doesn't exit, it hangs).

Could you take a look?

Cheers.

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

[Lldb-commits] [lldb] r339328 - Remove unused type Either from Utility library.

2018-08-09 Thread Tatyana Krasnukha via lldb-commits 
Author: tkrasnukha
Date: Thu Aug  9 04:42:28 2018
New Revision: 339328

URL: http://llvm.org/viewvc/llvm-project?rev=339328&view=rev
Log:
Remove unused type Either from Utility library.

Modified:
lldb/trunk/include/lldb/Utility/Either.h
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/include/lldb/Utility/Either.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/Either.h?rev=339328&r1=339327&r2=339328&view=diff
==
--- lldb/trunk/include/lldb/Utility/Either.h (original)
+++ lldb/trunk/include/lldb/Utility/Either.h Thu Aug  9 04:42:28 2018
@@ -12,115 +12,61 @@
 
 #include "llvm/ADT/Optional.h"
 
-#include 
-
 namespace lldb_utility {
-template  class Either {
-private:
-  enum class Selected { One, Two };
-
-  Selected m_selected;
-  union {
-T1 m_t1;
-T2 m_t2;
-  };
-
-public:
-  Either(const T1 &t1) {
-m_t1 = t1;
-m_selected = Selected::One;
-  }
-
-  Either(const T2 &t2) {
-m_t2 = t2;
-m_selected = Selected::Two;
-  }
-
-  Either(const Either &rhs) {
-switch (rhs.m_selected) {
-case Selected::One:
-  m_t1 = rhs.GetAs().getValue();
-  m_selected = Selected::One;
-  break;
-case Selected::Two:
-  m_t2 = rhs.GetAs().getValue();
-  m_selected = Selected::Two;
-  break;
-}
-  }
-
-  template ::value>::type
- * = nullptr>
-  llvm::Optional GetAs() const {
-switch (m_selected) {
-case Selected::One:
-  return m_t1;
-default:
-  return llvm::Optional();
-}
-  }
-
-  template ::value>::type
- * = nullptr>
-  llvm::Optional GetAs() const {
-switch (m_selected) {
-case Selected::Two:
-  return m_t2;
-default:
-  return llvm::Optional();
-}
-  }
-
-  template 
-  ResultType Apply(std::function if_T1,
-   std::function if_T2) const {
-switch (m_selected) {
-case Selected::One:
-  return if_T1(m_t1);
-case Selected::Two:
-  return if_T2(m_t2);
-}
-  }
-
-  bool operator==(const Either &rhs) {
-return (GetAs() == rhs.GetAs()) && (GetAs() == 
rhs.GetAs());
-  }
-
-  explicit operator bool() {
-switch (m_selected) {
-case Selected::One:
-  return (bool)m_t1;
-case Selected::Two:
-  return (bool)m_t2;
-}
-  }
-
-  Either &operator=(const Either &rhs) {
-switch (rhs.m_selected) {
-case Selected::One:
-  m_t1 = rhs.GetAs().getValue();
-  m_selected = Selected::One;
-  break;
-case Selected::Two:
-  m_t2 = rhs.GetAs().getValue();
-  m_selected = Selected::Two;
-  break;
-}
-return *this;
-  }
-
-  ~Either() {
-switch (m_selected) {
-case Selected::One:
-  m_t1.T1::~T1();
-  break;
-case Selected::Two:
-  m_t2.T2::~T2();
-  break;
-}
-  }
-};
-
+template 
+class Either {
+private:
+enum class Selected {
+One, Two
+};
+
+Selected m_selected;
+union {
+T1 m_t1;
+T2 m_t2;
+};
+
+public:
+Either(const T1& t1)
+{
+m_t1 = t1;
+m_selected = Selected::One;
+}
+
+Either(const T2& t2)
+{
+m_t2 = t2;
+m_selected = Selected::Two;
+}
+
+template ::value>::type * = nullptr >
+llvm::Optional
+GetAs()
+{
+switch (m_selected)
+{
+case Selected::One:
+return m_t1;
+default:
+return llvm::Optional();
+}
+}
+
+template ::value>::type * = nullptr >
+llvm::Optional
+GetAs()
+{
+switch (m_selected)
+{
+case Selected::Two:
+return m_t2;
+default:
+return llvm::Optional();
+}
+}
+};
+
 } // namespace lldb_utility
 
 #endif // #ifndef liblldb_Either_h_
+

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=339328&r1=339327&r2=339328&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Aug  9 04:42:28 2018
@@ -1777,7 +1777,6 @@
26CFDCA2186163A4000E63E5 /* Editline.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = Editline.cpp; sourceTree = ""; };
26CFDCA01861638D000E63E5 /* Editline.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
Editline.h; path = include/lldb/Host/Editline.h; sourceTree = ""; };
2326CF511BDD693B00A5CEAC /* EditlineTest.cpp

[Lldb-commits] [PATCH] D49739: Add new API to SBTarget class

2018-08-09 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added a subscriber: t.p.northover.
apolyakov added a comment.

It seems that `target-select-so-path.test` hangs on macOS. Thanks to 
@t.p.northover  for noting this.

The debugserver doesn't have `--pipe` option, so on macOS it fails to start and 
the test hangs waiting for output from debugserver. Is there any alternative 
for `--pipe` option to let the debugserver choose a tcp port itself? I took a 
quick look at debugserver's sources and didn't find it.


Repository:
  rL LLVM

https://reviews.llvm.org/D49739



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

[Lldb-commits] [lldb] r339343 - Darwin: mark test unsupported while we sort out how to make it generic.

2018-08-09 Thread Tim Northover via lldb-commits 
Author: tnorthover
Date: Thu Aug  9 06:21:05 2018
New Revision: 339343

URL: http://llvm.org/viewvc/llvm-project?rev=339343&view=rev
Log:
Darwin: mark test unsupported while we sort out how to make it generic.

This test relies on communicating with debugserver via an unnamed (pre-opened)
pipe, but macOS's version of debugserver doesn't seem to support that mode of
operation. So disable the test for now.

Modified:
lldb/trunk/lit/tools/lldb-mi/target/target-select-so-path.test

Modified: lldb/trunk/lit/tools/lldb-mi/target/target-select-so-path.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/tools/lldb-mi/target/target-select-so-path.test?rev=339343&r1=339342&r2=339343&view=diff
==
--- lldb/trunk/lit/tools/lldb-mi/target/target-select-so-path.test (original)
+++ lldb/trunk/lit/tools/lldb-mi/target/target-select-so-path.test Thu Aug  9 
06:21:05 2018
@@ -1,4 +1,4 @@
-# UNSUPPORTED: windows
+# UNSUPPORTED: windows, darwin
 #
 # RUN: %cc -o %t %p/inputs/main.c -g
 # RUN: python %p/inputs/target-select-so-path.py "%debugserver" "%lldbmi %t" %s


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

Re: [Lldb-commits] [PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

2018-08-09 Thread Greg Clayton via lldb-commits 


> On Aug 8, 2018, at 5:52 PM, Leonard Mosescu  wrote:
> 
> The LLDB MI plugin didn't work very well as was quite flaky when I tested it 
> a while back.
> 
> Just curious, what was the flaky part, the debug adapter or the LLDB MI 
> interface? 

Not sure. Debugging wasn't rock solid. Don't know where the blame lies.

> 
> On Wed, Aug 8, 2018 at 8:40 AM, Greg Clayton via Phabricator 
> mailto:revi...@reviews.llvm.org>> wrote:
> clayborg added a comment.
> 
> In https://reviews.llvm.org/D50365#1192447 
> , @zturner wrote:
> 
> > To elaborate, if you install the C/C++ plugin, and you go to Debug ->
> >  Configurations, and you go down to the MICmdMode property, it is by default
> >  set to "gdb".  But you can change this to "lldb" and it works out of the
> >  box.
> 
> 
> It is a different protocol. The LLDB MI plugin didn't work very well as was 
> quite flaky when I tested it a while back. Then I grabbed the CodeLLDB plugin 
> by Vadim Chugunov and it worked very well. When I looked more closely at this 
> plugin, it was using a javascript/typescript plug-in to launch a LLDB 
> instance and then ran a python script that received all of the javascript 
> packets from the javascript/typescript based plug-in and ran the debug 
> session using the python interpreter. It worked very well and was rock solid 
> stable. So I then created this plug-in for Nuclide for use at Facebook as 
> they switched all of the debugging plug-in over to use the VSCode debug 
> adaptor protocols. It works event better than the CodeLLDB plugin with Visual 
> Studio Code and it also doesn't stop you from using the python interpreter. 
> The issue I had with the CodeLLDB is that is uses the python interpreter to 
> run the debug session thus it isn't available to you as a LLDB user.
> 
> So long story short: our IDE at Facebook uses the VSCode protocol, MI is 
> clunky and doesn't work that well and was flaky, so this tool was created. 
> This also provides a really nice way to do remote debugging where the 
> lldb-vscode is run remotely on other systems. This removes the need for 
> copying files from a remote host up onto the system that is doing the 
> debugging. So we use this at Facebook and it also provides the best way to 
> use LLDB to debug using Visual Studio Code or Nuclide.
> 
> 
> https://reviews.llvm.org/D50365 
> 
> 
> 
> 

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

Re: [Lldb-commits] [lldb] r339178 - [lldb-mi] Re-implement target-select command

2018-08-09 Thread Davide Italiano via lldb-commits 
Feel free to revert this in the meanwhile, Tim, if you need to get the
bots going again.

--
Davide
On Thu, Aug 9, 2018 at 3:35 AM Tim Northover via lldb-commits
 wrote:
>
> Hi,
>
> I think this is causing the lldb-cmake test to hang on Green Dragon.
> The build revision numbers don't exactly match up for reasons I don't
> quite understand, but when I locally run check-lldb this is the test
> that spins for ages, and reverting this change doesn't move the
> timeout elsewhere.
>
> I think the root of the issue is that macOS's debugserver has a very
> different command-line interface from lldb-server, it bails and that
> causes the pipe read to hang. But there seem to be other issues when I
> try to run it manually too:
>
> tim@timn ~/llvm/llvm-project/lldb $
> /opt/local/Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
> /Users/tim/llvm/llvm-project/lldb/lit/tools/lldb-mi/target/inputs/target-select-so-path.py
> /Users/tim/llvm/build.lldb/bin/debugserver
> /Users/tim/llvm/build.lldb/bin/lldb-mi --synchronous
> /Users/tim/llvm/build.lldb/tools/lldb/lit/tools/lldb-mi/target/Output/target-select-so-path.test.tmp
> /Users/tim/llvm/llvm-project/lldb/lit/tools/lldb-mi/target/target-select-so-path.test
> FileCheck: Unknown command line argument '--synchronous'.  Try:
> 'FileCheck -help'
> FileCheck: Did you mean '-version'?
> FileCheck: Not enough positional command line arguments specified!
> Must specify at least 1 positional argument: See: FileCheck -help
> debugserver: unrecognized option `--pipe'
> debugserver-@(#)PROGRAM:LLDB  PROJECT:lldb-360.99.0
>  for x86_64.
> error: failed to launch process
> /Users/tim/llvm/build.lldb/bin/debugserver: No such file or directory
> (localhost:0)
> Exiting.
>
> (It doesn't exit, it hangs).
>
> Could you take a look?
>
> Cheers.
>
> Tim.
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r339351 - Also display the output and error output of a failed command

2018-08-09 Thread Raphael Isemann via lldb-commits 
Author: teemperor
Date: Thu Aug  9 08:29:32 2018
New Revision: 339351

URL: http://llvm.org/viewvc/llvm-project?rev=339351&view=rev
Log:
Also display the output and error output of a failed command

Summary:
Instead of just printing the current "False is not True, ..." message when we
fail to run a certain command, this patch also adds the actual command output or
error output that we received to the assertion message.

Reviewers: davide

Reviewed By: davide

Subscribers: lldb-commits

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

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

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=339351&r1=339350&r2=339351&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Thu Aug  9 08:29:32 
2018
@@ -2074,8 +2074,13 @@ class TestBase(Base):
 print("Command '" + cmd + "' failed!", file=sbuf)
 
 if check:
+output = ""
+if self.res.GetOutput():
+  output += "\nCommand output:\n" + self.res.GetOutput()
+if self.res.GetError():
+  output += "\nError output:\n" + self.res.GetError()
 self.assertTrue(self.res.Succeeded(),
-msg if msg else CMD_MSG(cmd))
+msg if (msg + output) else CMD_MSG(cmd + output))
 
 def match(
 self,


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

[Lldb-commits] [PATCH] D50492: Also display the output and error output of a failed command

2018-08-09 Thread Raphael Isemann via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB339351: Also display the output and error output of a 
failed command (authored by teemperor, committed by ).

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50492

Files:
  packages/Python/lldbsuite/test/lldbtest.py


Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -2074,8 +2074,13 @@
 print("Command '" + cmd + "' failed!", file=sbuf)
 
 if check:
+output = ""
+if self.res.GetOutput():
+  output += "\nCommand output:\n" + self.res.GetOutput()
+if self.res.GetError():
+  output += "\nError output:\n" + self.res.GetError()
 self.assertTrue(self.res.Succeeded(),
-msg if msg else CMD_MSG(cmd))
+msg if (msg + output) else CMD_MSG(cmd + output))
 
 def match(
 self,


Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -2074,8 +2074,13 @@
 print("Command '" + cmd + "' failed!", file=sbuf)
 
 if check:
+output = ""
+if self.res.GetOutput():
+  output += "\nCommand output:\n" + self.res.GetOutput()
+if self.res.GetError():
+  output += "\nError output:\n" + self.res.GetError()
 self.assertTrue(self.res.Succeeded(),
-msg if msg else CMD_MSG(cmd))
+msg if (msg + output) else CMD_MSG(cmd + output))
 
 def match(
 self,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r339328 - Remove unused type Either from Utility library.

2018-08-09 Thread Davide Italiano via lldb-commits 
On Thu, Aug 9, 2018 at 4:42 AM Tatyana Krasnukha via lldb-commits
 wrote:
>
> Author: tkrasnukha
> Date: Thu Aug  9 04:42:28 2018
> New Revision: 339328
>
> URL: http://llvm.org/viewvc/llvm-project?rev=339328&view=rev
> Log:
> Remove unused type Either from Utility library.
>

I might be missing the obvious here, but it looks like `Either.h` is
still around in my checkout after you removed it? (also, from the
xcodeproj files)

dcci@Davides-MacBook-Pro ~/w/l/l/t/lldb> ls ./include/lldb/Utility/Either.h
./include/lldb/Utility/Either.h

Do you plan to nuke the header from orbit completely?

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

[Lldb-commits] [lldb] r339353 - Added missing null checks to fix r339351

2018-08-09 Thread Raphael Isemann via lldb-commits 
Author: teemperor
Date: Thu Aug  9 08:57:43 2018
New Revision: 339353

URL: http://llvm.org/viewvc/llvm-project?rev=339353&view=rev
Log:
Added missing null checks to fix r339351

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

Modified: lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py?rev=339353&r1=339352&r2=339353&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Thu Aug  9 08:57:43 
2018
@@ -2079,8 +2079,12 @@ class TestBase(Base):
   output += "\nCommand output:\n" + self.res.GetOutput()
 if self.res.GetError():
   output += "\nError output:\n" + self.res.GetError()
+if msg:
+  msg += output
+if cmd:
+  cmd += output
 self.assertTrue(self.res.Succeeded(),
-msg if (msg + output) else CMD_MSG(cmd + output))
+msg if (msg) else CMD_MSG(cmd))
 
 def match(
 self,


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

[Lldb-commits] [PATCH] D50473: [Demangle] Add another test for ItaniumPartialDemangler

2018-08-09 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

BTW: warning I saw during recent build:

  [98/790] Building CXX object 
tools/lldb/source/Core/CMakeFiles/lldbCore.dir/RichManglingContext.cpp.o
  
/home/gclayton/local/src/llvm/svn/llvm/tools/lldb/source/Core/RichManglingContext.cpp:
 In member function ‘bool lldb_private::RichManglingContext::IsCtorOrDtor() 
const’:
  
/home/gclayton/local/src/llvm/svn/llvm/tools/lldb/source/Core/RichManglingContext.cpp:77:1:
 warning: control reaches end of non-void function [-Wreturn-type]
   }
   ^
  
/home/gclayton/local/src/llvm/svn/llvm/tools/lldb/source/Core/RichManglingContext.cpp:
 In member function ‘bool lldb_private::RichManglingContext::IsFunction() 
const’:
  
/home/gclayton/local/src/llvm/svn/llvm/tools/lldb/source/Core/RichManglingContext.cpp:89:1:
 warning: control reaches end of non-void function [-Wreturn-type]
   }
   ^


Repository:
  rL LLVM

https://reviews.llvm.org/D50473



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

Re: [Lldb-commits] [lldb] r339178 - [lldb-mi] Re-implement target-select command

2018-08-09 Thread Tim Northover via lldb-commits 
On Thu, 9 Aug 2018 at 16:28, Davide Italiano  wrote:
> Feel free to revert this in the meanwhile, Tim, if you need to get the
> bots going again.

Thanks Davide. I've marked it unsupported after some discussion with
Александр, as a slightly less intrusive solution.

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

Re: [Lldb-commits] [PATCH] D49739: Add new API to SBTarget class

2018-08-09 Thread Jim Ingham via lldb-commits 
It looks like lots of options to debugserver were added without also adding 
them to the --help output.  Probably because there are so few clients they 
already know the options (the same person added & used them...)  But if you 
look at the actual options in debugserver.cpp, you will see:

{"unix-socket", required_argument, NULL,
 'u'}, // If we need to handshake with our parent process, an option will be
   // passed down that specifies a unix socket name to use
{"fd", required_argument, NULL,
 '2'}, // A file descriptor was passed to this process when spawned that
   // is already open and ready for communication
{"named-pipe", required_argument, NULL, 'P'},
{"reverse-connect", no_argument, NULL, 'R'},

Will one of those serve your purpose?

Jim

> On Aug 9, 2018, at 6:20 AM, Alexander Polyakov via Phabricator 
>  wrote:
> 
> apolyakov added a subscriber: t.p.northover.
> apolyakov added a comment.
> 
> It seems that `target-select-so-path.test` hangs on macOS. Thanks to 
> @t.p.northover  for noting this.
> 
> The debugserver doesn't have `--pipe` option, so on macOS it fails to start 
> and the test hangs waiting for output from debugserver. Is there any 
> alternative for `--pipe` option to let the debugserver choose a tcp port 
> itself? I took a quick look at debugserver's sources and didn't find it.
> 
> 
> Repository:
>  rL LLVM
> 
> https://reviews.llvm.org/D49739
> 
> 
> 

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

[Lldb-commits] [PATCH] D49739: Add new API to SBTarget class

2018-08-09 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a subscriber: apolyakov.
jingham added a comment.

It looks like lots of options to debugserver were added without also adding 
them to the --help output.  Probably because there are so few clients they 
already know the options (the same person added & used them...)  But if you 
look at the actual options in debugserver.cpp, you will see:

  {"unix-socket", required_argument, NULL,
   'u'}, // If we need to handshake with our parent process, an option will be
 // passed down that specifies a unix socket name to use
  {"fd", required_argument, NULL,
   '2'}, // A file descriptor was passed to this process when spawned that
 // is already open and ready for communication
  {"named-pipe", required_argument, NULL, 'P'},
  {"reverse-connect", no_argument, NULL, 'R'},

Will one of those serve your purpose?

Jim


Repository:
  rL LLVM

https://reviews.llvm.org/D49739



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

[Lldb-commits] [PATCH] D49739: Add new API to SBTarget class

2018-08-09 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added a comment.

I think those options don't fit. I'm looking for behavior like this:

  ~/workspace/gsoc/build/bin/lldb-server gdbserver --pipe 1 localhost:0
  36251

Here lldb-server prints out the port number he is listening on and continues 
running.

If debugserver can choose a tcp port in case of passed `hostname:0` then 
probably all we need to do is to add analogue of `--pipe` option.


Repository:
  rL LLVM

https://reviews.llvm.org/D49739



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

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov created this revision.
apolyakov added reviewers: aprantl, clayborg, jingham, labath.
Herald added a subscriber: ki.stfu.

In this patch I move some of interpreter tests from python to LIT(I will move 
all interpreter test if these are OK). It's a WIP since I want to get your 
opinion about tests like target-list.test. As you may see, in this test we must 
run lldb-mi without passing an executable, it means that we can't pass it to 
lldb-mi through LIT. As a solution, I hardcoded executable name as a.exe. What 
do you think about this approach? We already have one test with hardcoded 
executable name - lit/tools/lldb-mi/breakpoint/break-insert.test, but I want to 
be sure that it's OK.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525

Files:
  lit/tools/lldb-mi/interpreter/cli-support/breakpoint-set.test
  lit/tools/lldb-mi/interpreter/cli-support/inputs/main.cpp
  lit/tools/lldb-mi/interpreter/cli-support/lit.local.cfg
  lit/tools/lldb-mi/interpreter/cli-support/settings-set-target-run-after.test
  lit/tools/lldb-mi/interpreter/cli-support/settings-set-target-run-before.test
  lit/tools/lldb-mi/interpreter/cli-support/target-create.test
  lit/tools/lldb-mi/interpreter/cli-support/target-list.test

Index: lit/tools/lldb-mi/interpreter/cli-support/target-list.test
===
--- /dev/null
+++ lit/tools/lldb-mi/interpreter/cli-support/target-list.test
@@ -0,0 +1,20 @@
+# XFAIL: windows
+# -> llvm.org/pr24452
+#
+# We should hardcode executable name since at the moment of running of
+# lldb-mi the name must be known.
+# RUN: %cxx -o a.exe %p/inputs/main.cpp -g
+# RUN: %lldbmi < %s | FileCheck %s
+
+# Test lldb-mi CLI support. 'target list' command.
+
+target list
+# CHECK: ~"No targets.\n"
+
+-file-exec-and-symbols a.exe
+# CHECK: ^done
+
+target list
+# CHECK: ~"Current targets:\n* target #0: {{.*}}a.exe{{.*}}\n"
+
+-gdb-exit
Index: lit/tools/lldb-mi/interpreter/cli-support/target-create.test
===
--- /dev/null
+++ lit/tools/lldb-mi/interpreter/cli-support/target-create.test
@@ -0,0 +1,21 @@
+# XFAIL: windows
+# -> llvm.org/pr24452
+#
+# We should hardcode executable name since at the moment of running of
+# lldb-mi the name must be known.
+# RUN: %cxx -o a.exe %p/inputs/main.cpp -g
+# RUN: %lldbmi < %s | FileCheck %s
+
+# Test lldb-mi CLI support. 'target create' command.
+
+target create a.exe
+# CHECK: ^done
+
+-break-insert -f main
+# CHECK: ^done,bkpt={number="1"
+
+-exec-run
+# CHECK: ^running
+# CHECK: *stopped,reason="breakpoint-hit"
+
+-gdb-exit
Index: lit/tools/lldb-mi/interpreter/cli-support/settings-set-target-run-before.test
===
--- /dev/null
+++ lit/tools/lldb-mi/interpreter/cli-support/settings-set-target-run-before.test
@@ -0,0 +1,23 @@
+# XFAIL: windows
+# -> llvm.org/pr24452
+#
+# We should hardcode executable name since at the moment of running of
+# lldb-mi the name must be known.
+# RUN: %cxx -o a.exe %p/inputs/main.cpp -g
+# RUN: %lldbmi < %s | FileCheck %s
+
+# Test lldb-mi CLI support. 'setting set target.run-args' command before than
+# target was created.
+
+# FIXME: --arg1 causes an error.
+setting set target.run-args arg1 "2nd arg" third_arg fourth="4th arg"
+# CHECK: ^done
+
+-file-exec-and-symbols a.exe
+# CHECK: ^done
+
+-exec-run
+# CHECK: ^running
+# CHECK: @"argc=5\r\n"
+
+-gdb-exit
Index: lit/tools/lldb-mi/interpreter/cli-support/settings-set-target-run-after.test
===
--- /dev/null
+++ lit/tools/lldb-mi/interpreter/cli-support/settings-set-target-run-after.test
@@ -0,0 +1,21 @@
+# XFAIL: windows
+# -> llvm.org/pr24452
+#
+# RUN: %cxx -o %t %p/inputs/main.cpp -g
+# RUN: %lldbmi %t < %s | FileCheck %s
+
+# Test lldb-mi CLI support. 'setting set target.run-args' command after than
+# target was created.
+
+# Check that we have a valid target created via '%lldbmi %t'.
+# CHECK: ^done
+
+# FIXME: --arg1 causes an error.
+setting set target.run-args arg1 "2nd arg" third_arg fourth="4th arg"
+# CHECK: ^done
+
+-exec-run
+# CHECK: ^running
+# CHECK: @"argc=5\r\n"
+
+-gdb-exit
Index: lit/tools/lldb-mi/interpreter/cli-support/lit.local.cfg
===
--- /dev/null
+++ lit/tools/lldb-mi/interpreter/cli-support/lit.local.cfg
@@ -0,0 +1 @@
+config.suffixes = ['.test']
Index: lit/tools/lldb-mi/interpreter/cli-support/inputs/main.cpp
===
--- /dev/null
+++ lit/tools/lldb-mi/interpreter/cli-support/inputs/main.cpp
@@ -0,0 +1,19 @@
+//===-- main.cpp *- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===-

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Stella Stamenova via Phabricator via lldb-commits 
stella.stamenova added inline comments.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/breakpoint-set.test:4
+#
+# RUN: %cxx -o %t %p/inputs/main.cpp -g
+# RUN: %lldbmi %t < %s | FileCheck %s

One thing to consider here is that any extra parameters passed with -E to the 
test suite will not propagate to lit at the moment.

I ran into this with some internal testing where we need to pass parameters to 
the compiler - all of the lldb suite tests (c++ and c) build correctly, but any 
lit tests that directly invoke the compiler do not because the parameters do 
not get propagated all the way.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525



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

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added inline comments.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/breakpoint-set.test:4
+#
+# RUN: %cxx -o %t %p/inputs/main.cpp -g
+# RUN: %lldbmi %t < %s | FileCheck %s

stella.stamenova wrote:
> One thing to consider here is that any extra parameters passed with -E to the 
> test suite will not propagate to lit at the moment.
> 
> I ran into this with some internal testing where we need to pass parameters 
> to the compiler - all of the lldb suite tests (c++ and c) build correctly, 
> but any lit tests that directly invoke the compiler do not because the 
> parameters do not get propagated all the way.
Could you give an example of extra parameters? I didn't see them before so I 
don't completely understand you.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525



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

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Stella Stamenova via Phabricator via lldb-commits 
stella.stamenova added inline comments.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/breakpoint-set.test:4
+#
+# RUN: %cxx -o %t %p/inputs/main.cpp -g
+# RUN: %lldbmi %t < %s | FileCheck %s

apolyakov wrote:
> stella.stamenova wrote:
> > One thing to consider here is that any extra parameters passed with -E to 
> > the test suite will not propagate to lit at the moment.
> > 
> > I ran into this with some internal testing where we need to pass parameters 
> > to the compiler - all of the lldb suite tests (c++ and c) build correctly, 
> > but any lit tests that directly invoke the compiler do not because the 
> > parameters do not get propagated all the way.
> Could you give an example of extra parameters? I didn't see them before so I 
> don't completely understand you.
-E "--sysroot=path/to/sys/root -lc++abi -lunwind"


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525



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

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added inline comments.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/breakpoint-set.test:4
+#
+# RUN: %cxx -o %t %p/inputs/main.cpp -g
+# RUN: %lldbmi %t < %s | FileCheck %s

stella.stamenova wrote:
> apolyakov wrote:
> > stella.stamenova wrote:
> > > One thing to consider here is that any extra parameters passed with -E to 
> > > the test suite will not propagate to lit at the moment.
> > > 
> > > I ran into this with some internal testing where we need to pass 
> > > parameters to the compiler - all of the lldb suite tests (c++ and c) 
> > > build correctly, but any lit tests that directly invoke the compiler do 
> > > not because the parameters do not get propagated all the way.
> > Could you give an example of extra parameters? I didn't see them before so 
> > I don't completely understand you.
> -E "--sysroot=path/to/sys/root -lc++abi -lunwind"
Ok, I think we won't use something like it here. Thank you.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525



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

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl added inline comments.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/target-list.test:5
+# We should hardcode executable name since at the moment of running of
+# lldb-mi the name must be known.
+# RUN: %cxx -o a.exe %p/inputs/main.cpp -g

That's totally fine, we just need to choose a name that works on all platforms, 
and `a.exe` does.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/target-list.test:18
+target list
+# CHECK: ~"Current targets:\n* target #0: {{.*}}a.exe{{.*}}\n"
+

Does lldb-mi echo the comment lines? If yes, you need to be careful that 
FileCheck doesn't match against the input, e.g., by adding `{{^}}` to the 
beginning of each CHECK command. If it doesn't, then that's fine.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525



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

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added inline comments.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/target-list.test:18
+target list
+# CHECK: ~"Current targets:\n* target #0: {{.*}}a.exe{{.*}}\n"
+

aprantl wrote:
> Does lldb-mi echo the comment lines? If yes, you need to be careful that 
> FileCheck doesn't match against the input, e.g., by adding `{{^}}` to the 
> beginning of each CHECK command. If it doesn't, then that's fine.
It doesn't. I passed `# CHECK: some_text` and got only:
```
^done
(gdb)

```


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525



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

[Lldb-commits] [PATCH] D50536: Fix: ConstString::GetConstCStringAndSetMangledCounterPart() should update the value if the key exists already

2018-08-09 Thread Stefan Gränitz via Phabricator via lldb-commits 
sgraenitz created this revision.
sgraenitz added reviewers: jingham, friss, labath.

This issue came up because it caused problems in our unit tests. The StringPool 
did connect counterparts only once and silently ignored the values passed in 
subsequent calls.
The simplest solution for the unit tests would be silent overwrite. In 
practice, however, it seems useful to assert that we never overwrite a 
different mangled counterpart.
If we ever have mangled counterparts for other languages than C++, this makes 
it more likely to notice collisions.

I added an assertion that allows the following cases:

- inserting a new value
- overwriting the empty string
- overwriting with an identical value

I fixed the unit tests, which used "random" strings and thus produced 
collisions.
It would be even better if there was a way to reset or isolate the StringPool, 
but that's a different story.


https://reviews.llvm.org/D50536

Files:
  source/Utility/ConstString.cpp
  unittests/Utility/ConstStringTest.cpp


Index: unittests/Utility/ConstStringTest.cpp
===
--- unittests/Utility/ConstStringTest.cpp
+++ unittests/Utility/ConstStringTest.cpp
@@ -18,40 +18,56 @@
 }
 
 TEST(ConstStringTest, MangledCounterpart) {
-  ConstString foo("foo");
+  ConstString uvw("uvw");
   ConstString counterpart;
-  EXPECT_FALSE(foo.GetMangledCounterpart(counterpart));
+  EXPECT_FALSE(uvw.GetMangledCounterpart(counterpart));
   EXPECT_EQ("", counterpart.GetStringRef());
 
-  ConstString bar;
-  bar.SetStringWithMangledCounterpart("bar", foo);
-  EXPECT_EQ("bar", bar.GetStringRef());
+  ConstString xyz;
+  xyz.SetStringWithMangledCounterpart("xyz", uvw);
+  EXPECT_EQ("xyz", xyz.GetStringRef());
 
-  EXPECT_TRUE(bar.GetMangledCounterpart(counterpart));
-  EXPECT_EQ("foo", counterpart.GetStringRef());
+  EXPECT_TRUE(xyz.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("uvw", counterpart.GetStringRef());
 
-  EXPECT_TRUE(foo.GetMangledCounterpart(counterpart));
-  EXPECT_EQ("bar", counterpart.GetStringRef());
+  EXPECT_TRUE(uvw.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("xyz", counterpart.GetStringRef());
+}
+
+TEST(ConstStringTest, UpdateMangledCounterpart) {
+  { // Init counterpart with empty string
+ConstString some1;
+some1.SetStringWithMangledCounterpart("some", ConstString(""));
+  }
+  { // Update counterpart to "one"
+ConstString some2;
+some2.SetStringWithMangledCounterpart("some", ConstString("one"));
+  }
+  { // Check counterpart is "one"
+ConstString counterpart;
+EXPECT_TRUE(ConstString("some").GetMangledCounterpart(counterpart));
+EXPECT_EQ("one", counterpart.GetStringRef());
+  }
 }
 
 TEST(ConstStringTest, FromMidOfBufferStringRef) {
   // StringRef's into bigger buffer: no null termination
-  const char *buffer = "foobarbaz";
+  const char *buffer = "abcdefghi";
   llvm::StringRef foo_ref(buffer, 3);
   llvm::StringRef bar_ref(buffer + 3, 3);
 
   ConstString foo(foo_ref);
 
   ConstString bar;
   bar.SetStringWithMangledCounterpart(bar_ref, foo);
-  EXPECT_EQ("bar", bar.GetStringRef());
+  EXPECT_EQ("def", bar.GetStringRef());
 
   ConstString counterpart;
   EXPECT_TRUE(bar.GetMangledCounterpart(counterpart));
-  EXPECT_EQ("foo", counterpart.GetStringRef());
+  EXPECT_EQ("abc", counterpart.GetStringRef());
 
   EXPECT_TRUE(foo.GetMangledCounterpart(counterpart));
-  EXPECT_EQ("bar", counterpart.GetStringRef());
+  EXPECT_EQ("def", counterpart.GetStringRef());
 }
 
 TEST(ConstStringTest, NullAndEmptyStates) {
Index: source/Utility/ConstString.cpp
===
--- source/Utility/ConstString.cpp
+++ source/Utility/ConstString.cpp
@@ -119,11 +119,15 @@
   const uint8_t h = hash(demangled);
   llvm::sys::SmartScopedWriter wlock(m_string_pools[h].m_mutex);
 
-  // Make string pool entry with the mangled counterpart already set
-  StringPoolEntryType &entry =
-  *m_string_pools[h]
-   .m_string_map.insert(std::make_pair(demangled, mangled_ccstr))
-   .first;
+  StringPool &map = m_string_pools[h].m_string_map;
+  assert((map.find(demangled) == map.end() || strlen(map[demangled]) == 0 
||
+ map[demangled] == mangled_ccstr) &&
+ "The demangled string must have a unique counterpart or otherwise 
"
+ "it must be empty");
+
+  // Make or update string pool entry with the mangled counterpart
+  StringPoolEntryType &entry = *map.try_emplace(demangled).first;
+  entry.second = mangled_ccstr;
 
   // Extract the const version of the demangled_cstr
   demangled_ccstr = entry.getKeyData();


Index: unittests/Utility/ConstStringTest.cpp
===
--- unittests/Utility/ConstStringTest.cpp
+++ unittests/Utility/ConstStringTest.cpp
@@ -18,40 +18,56 @@
 }
 
 TEST(ConstStringTest, MangledCounterpart) {
-  ConstString foo("foo");
+

[Lldb-commits] [PATCH] D50536: Fix: ConstString::GetConstCStringAndSetMangledCounterPart() should update the value if the key exists already

2018-08-09 Thread Stefan Gränitz via Phabricator via lldb-commits 
sgraenitz updated this revision to Diff 160014.
sgraenitz added a comment.

Show allowed cases in ConstStringTest.UpdateMangledCounterpart and format


https://reviews.llvm.org/D50536

Files:
  source/Utility/ConstString.cpp
  unittests/Utility/ConstStringTest.cpp

Index: unittests/Utility/ConstStringTest.cpp
===
--- unittests/Utility/ConstStringTest.cpp
+++ unittests/Utility/ConstStringTest.cpp
@@ -18,40 +18,60 @@
 }
 
 TEST(ConstStringTest, MangledCounterpart) {
-  ConstString foo("foo");
+  ConstString uvw("uvw");
   ConstString counterpart;
-  EXPECT_FALSE(foo.GetMangledCounterpart(counterpart));
+  EXPECT_FALSE(uvw.GetMangledCounterpart(counterpart));
   EXPECT_EQ("", counterpart.GetStringRef());
 
-  ConstString bar;
-  bar.SetStringWithMangledCounterpart("bar", foo);
-  EXPECT_EQ("bar", bar.GetStringRef());
+  ConstString xyz;
+  xyz.SetStringWithMangledCounterpart("xyz", uvw);
+  EXPECT_EQ("xyz", xyz.GetStringRef());
 
-  EXPECT_TRUE(bar.GetMangledCounterpart(counterpart));
-  EXPECT_EQ("foo", counterpart.GetStringRef());
+  EXPECT_TRUE(xyz.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("uvw", counterpart.GetStringRef());
 
-  EXPECT_TRUE(foo.GetMangledCounterpart(counterpart));
-  EXPECT_EQ("bar", counterpart.GetStringRef());
+  EXPECT_TRUE(uvw.GetMangledCounterpart(counterpart));
+  EXPECT_EQ("xyz", counterpart.GetStringRef());
+}
+
+TEST(ConstStringTest, UpdateMangledCounterpart) {
+  { // Add counterpart
+ConstString some1;
+some1.SetStringWithMangledCounterpart("some", ConstString(""));
+  }
+  { // Overwrite empty string
+ConstString some2;
+some2.SetStringWithMangledCounterpart("some", ConstString("one"));
+  }
+  { // Overwrite with identical value
+ConstString some2;
+some2.SetStringWithMangledCounterpart("some", ConstString("one"));
+  }
+  { // Check counterpart is set
+ConstString counterpart;
+EXPECT_TRUE(ConstString("some").GetMangledCounterpart(counterpart));
+EXPECT_EQ("one", counterpart.GetStringRef());
+  }
 }
 
 TEST(ConstStringTest, FromMidOfBufferStringRef) {
   // StringRef's into bigger buffer: no null termination
-  const char *buffer = "foobarbaz";
+  const char *buffer = "abcdefghi";
   llvm::StringRef foo_ref(buffer, 3);
   llvm::StringRef bar_ref(buffer + 3, 3);
 
   ConstString foo(foo_ref);
 
   ConstString bar;
   bar.SetStringWithMangledCounterpart(bar_ref, foo);
-  EXPECT_EQ("bar", bar.GetStringRef());
+  EXPECT_EQ("def", bar.GetStringRef());
 
   ConstString counterpart;
   EXPECT_TRUE(bar.GetMangledCounterpart(counterpart));
-  EXPECT_EQ("foo", counterpart.GetStringRef());
+  EXPECT_EQ("abc", counterpart.GetStringRef());
 
   EXPECT_TRUE(foo.GetMangledCounterpart(counterpart));
-  EXPECT_EQ("bar", counterpart.GetStringRef());
+  EXPECT_EQ("def", counterpart.GetStringRef());
 }
 
 TEST(ConstStringTest, NullAndEmptyStates) {
Index: source/Utility/ConstString.cpp
===
--- source/Utility/ConstString.cpp
+++ source/Utility/ConstString.cpp
@@ -119,11 +119,15 @@
   const uint8_t h = hash(demangled);
   llvm::sys::SmartScopedWriter wlock(m_string_pools[h].m_mutex);
 
-  // Make string pool entry with the mangled counterpart already set
-  StringPoolEntryType &entry =
-  *m_string_pools[h]
-   .m_string_map.insert(std::make_pair(demangled, mangled_ccstr))
-   .first;
+  StringPool &map = m_string_pools[h].m_string_map;
+  assert((map.find(demangled) == map.end() || strlen(map[demangled]) == 0 ||
+  map[demangled] == mangled_ccstr) &&
+ "The demangled string must have a unique counterpart or otherwise "
+ "it must be empty");
+
+  // Make or update string pool entry with the mangled counterpart
+  StringPoolEntryType &entry = *map.try_emplace(demangled).first;
+  entry.second = mangled_ccstr;
 
   // Extract the const version of the demangled_cstr
   demangled_ccstr = entry.getKeyData();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Stella Stamenova via Phabricator via lldb-commits 
stella.stamenova requested changes to this revision.
stella.stamenova added inline comments.
This revision now requires changes to proceed.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/breakpoint-set.test:4
+#
+# RUN: %cxx -o %t %p/inputs/main.cpp -g
+# RUN: %lldbmi %t < %s | FileCheck %s

apolyakov wrote:
> stella.stamenova wrote:
> > apolyakov wrote:
> > > stella.stamenova wrote:
> > > > One thing to consider here is that any extra parameters passed with -E 
> > > > to the test suite will not propagate to lit at the moment.
> > > > 
> > > > I ran into this with some internal testing where we need to pass 
> > > > parameters to the compiler - all of the lldb suite tests (c++ and c) 
> > > > build correctly, but any lit tests that directly invoke the compiler do 
> > > > not because the parameters do not get propagated all the way.
> > > Could you give an example of extra parameters? I didn't see them before 
> > > so I don't completely understand you.
> > -E "--sysroot=path/to/sys/root -lc++abi -lunwind"
> Ok, I think we won't use something like it here. Thank you.
I think you misunderstood my concern - let's say I have a machine on which I 
run these tests for a particular architecture that depends on passing these 
arguments to the tests, so that clang (cxx) correctly complies c++ files. 
*Before* your change, these arguments would have been propagated to the test in 
the lldb suite and the code would have build correctly. *After* your change, 
the code will no longer build correctly.

Essentially, by making these tests lit tests, you are removing support for 
passing these arguments to the compiler (since the lldb suite supports them and 
lit does not). It might still be worth making these lit tests for the sake of 
other benefits, but then such targets will end up having to XFAIL the tests.

If these tests really need to become lit tests and invoke the compiler, I think 
you also need to add support for passing these arguments to the compiler.



Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525



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

[Lldb-commits] [PATCH] D50525: [WIP] Move lldb-mi interpreter tests to LIT

2018-08-09 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl added inline comments.



Comment at: lit/tools/lldb-mi/interpreter/cli-support/breakpoint-set.test:4
+#
+# RUN: %cxx -o %t %p/inputs/main.cpp -g
+# RUN: %lldbmi %t < %s | FileCheck %s

stella.stamenova wrote:
> apolyakov wrote:
> > stella.stamenova wrote:
> > > apolyakov wrote:
> > > > stella.stamenova wrote:
> > > > > One thing to consider here is that any extra parameters passed with 
> > > > > -E to the test suite will not propagate to lit at the moment.
> > > > > 
> > > > > I ran into this with some internal testing where we need to pass 
> > > > > parameters to the compiler - all of the lldb suite tests (c++ and c) 
> > > > > build correctly, but any lit tests that directly invoke the compiler 
> > > > > do not because the parameters do not get propagated all the way.
> > > > Could you give an example of extra parameters? I didn't see them before 
> > > > so I don't completely understand you.
> > > -E "--sysroot=path/to/sys/root -lc++abi -lunwind"
> > Ok, I think we won't use something like it here. Thank you.
> I think you misunderstood my concern - let's say I have a machine on which I 
> run these tests for a particular architecture that depends on passing these 
> arguments to the tests, so that clang (cxx) correctly complies c++ files. 
> *Before* your change, these arguments would have been propagated to the test 
> in the lldb suite and the code would have build correctly. *After* your 
> change, the code will no longer build correctly.
> 
> Essentially, by making these tests lit tests, you are removing support for 
> passing these arguments to the compiler (since the lldb suite supports them 
> and lit does not). It might still be worth making these lit tests for the 
> sake of other benefits, but then such targets will end up having to XFAIL the 
> tests.
> 
> If these tests really need to become lit tests and invoke the compiler, I 
> think you also need to add support for passing these arguments to the 
> compiler.
> 
I think the best way to solve this is by adding the platform-specific flags to 
the expansion of `%cxx` in the lit configuration. Would that work here?


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D50525



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