date:20190302

[Lldb-commits] [PATCH] D58871: [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

2019-03-02 Thread Michał Górny via Phabricator via lldb-commits

mgorny created this revision.
mgorny added reviewers: krytarowski, labath.
Herald added a subscriber: abidh.
Herald added a reviewer: serge-sans-paille.
Herald added a project: LLDB.

Remove the code forcing -stdlib=libstdc++ on NetBSD in getBuildFlags()
method.  NetBSD uses libc++ everywhere else, and using libstdc++ here
causes lang/cpp/dynamic-value to fail to build.

NB: I have no clue what `getBuildFlags()` is supposed to do, and why it's used 
in the few tests it's used in, so the change can be entirely wrong. However, 
tests pass for me with it, and it fixes missing symbols I've had when building 
with libstdc++.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D58871

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


Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1666,7 +1666,8 @@
 elif self.getPlatform() == "openbsd":
 cflags += " -stdlib=libc++"
 elif self.getPlatform() == "netbsd":
-cflags += " -stdlib=libstdc++"
+# NetBSD defaults to libc++
+pass
 elif "clang" in self.getCompiler():
 cflags += " -stdlib=libstdc++"
 


Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1666,7 +1666,8 @@
 elif self.getPlatform() == "openbsd":
 cflags += " -stdlib=libc++"
 elif self.getPlatform() == "netbsd":
-cflags += " -stdlib=libstdc++"
+# NetBSD defaults to libc++
+pass
 elif "clang" in self.getCompiler():
 cflags += " -stdlib=libstdc++"
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58860: [build.py] Allow clang-cl to build files starting with '/U'

2019-03-02 Thread Pavel Labath via Phabricator via lldb-commits

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

Seems straight-forward enough.


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

https://reviews.llvm.org/D58860



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

[Lldb-commits] [PATCH] D58871: [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

2019-03-02 Thread Pavel Labath via Phabricator via lldb-commits

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

hmm.. interesting. I had no idea this function even exists. It's existence if 
unfortunate as it seems to duplicate some of the logic already present in 
makefiles, but that's not your problem here.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D58871



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

[Lldb-commits] [lldb] r355270 - Fix gcc build for r355249

2019-03-02 Thread Pavel Labath via lldb-commits

Author: labath
Date: Sat Mar  2 08:23:07 2019
New Revision: 355270

URL: http://llvm.org/viewvc/llvm-project?rev=355270&view=rev
Log:
Fix gcc build for r355249

automatic move should not fire when returning type T in a function with
result type Expected. Some compilers seem to allow that nonetheless.

Modified:
lldb/trunk/source/Utility/Reproducer.cpp

Modified: lldb/trunk/source/Utility/Reproducer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/Reproducer.cpp?rev=355270&r1=355269&r2=355270&view=diff
==
--- lldb/trunk/source/Utility/Reproducer.cpp (original)
+++ lldb/trunk/source/Utility/Reproducer.cpp Sat Mar  2 08:23:07 2019
@@ -226,7 +226,7 @@ DataRecorder::Create(FileSpec filename)
   auto recorder = llvm::make_unique(std::move(filename), ec);
   if (ec)
 return llvm::errorCodeToError(ec);
-  return recorder;
+  return std::move(recorder);
 }
 
 DataRecorder *CommandProvider::GetNewDataRecorder() {


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

[Lldb-commits] [lldb] r355273 - [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

2019-03-02 Thread Michal Gorny via lldb-commits

Author: mgorny
Date: Sat Mar  2 08:46:29 2019
New Revision: 355273

URL: http://llvm.org/viewvc/llvm-project?rev=355273&view=rev
Log:
[lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

Remove the code forcing -stdlib=libstdc++ on NetBSD in getBuildFlags()
method.  NetBSD uses libc++ everywhere else, and using libstdc++ here
causes lang/cpp/dynamic-value to fail to build.

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

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=355273&r1=355272&r2=355273&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py Sat Mar  2 08:46:29 
2019
@@ -1666,7 +1666,8 @@ class Base(unittest2.TestCase):
 elif self.getPlatform() == "openbsd":
 cflags += " -stdlib=libc++"
 elif self.getPlatform() == "netbsd":
-cflags += " -stdlib=libstdc++"
+# NetBSD defaults to libc++
+pass
 elif "clang" in self.getCompiler():
 cflags += " -stdlib=libstdc++"
 


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

[Lldb-commits] [lldb] r355274 - [lldb] [lit] Pass -pthread on NetBSD as well

2019-03-02 Thread Michal Gorny via lldb-commits

Author: mgorny
Date: Sat Mar  2 08:48:44 2019
New Revision: 355274

URL: http://llvm.org/viewvc/llvm-project?rev=355274&view=rev
Log:
[lldb] [lit] Pass -pthread on NetBSD as well

Modified:
lldb/trunk/lit/helper/toolchain.py

Modified: lldb/trunk/lit/helper/toolchain.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/helper/toolchain.py?rev=355274&r1=355273&r2=355274&view=diff
==
--- lldb/trunk/lit/helper/toolchain.py (original)
+++ lldb/trunk/lit/helper/toolchain.py Sat Mar  2 08:48:44 2019
@@ -96,7 +96,7 @@ def use_support_substitutions(config):
 sdk_path = lit.util.to_string(out)
 llvm_config.lit_config.note('using SDKROOT: %r' % sdk_path)
 flags = ['-isysroot', sdk_path]
-elif platform.system() in ['OpenBSD', 'Linux']:
+elif platform.system() in ['NetBSD', 'OpenBSD', 'Linux']:
 flags = ['-pthread']
 
 


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

[Lldb-commits] [PATCH] D58871: [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

2019-03-02 Thread Michał Górny via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rLLDB355273: [lldb] [lldbtest] Fix getBuildFlags() not to use 
libstdc++ on NetBSD (authored by mgorny, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D58871?vs=189040&id=189051#toc

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D58871

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
@@ -1666,7 +1666,8 @@
 elif self.getPlatform() == "openbsd":
 cflags += " -stdlib=libc++"
 elif self.getPlatform() == "netbsd":
-cflags += " -stdlib=libstdc++"
+# NetBSD defaults to libc++
+pass
 elif "clang" in self.getCompiler():
 cflags += " -stdlib=libstdc++"
 


Index: packages/Python/lldbsuite/test/lldbtest.py
===
--- packages/Python/lldbsuite/test/lldbtest.py
+++ packages/Python/lldbsuite/test/lldbtest.py
@@ -1666,7 +1666,8 @@
 elif self.getPlatform() == "openbsd":
 cflags += " -stdlib=libc++"
 elif self.getPlatform() == "netbsd":
-cflags += " -stdlib=libstdc++"
+# NetBSD defaults to libc++
+pass
 elif "clang" in self.getCompiler():
 cflags += " -stdlib=libstdc++"
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r355276 - Reinstate UNSUPPORTED: linux on stop-hook-threads.test

2019-03-02 Thread Pavel Labath via lldb-commits

Author: labath
Date: Sat Mar  2 11:58:10 2019
New Revision: 355276

URL: http://llvm.org/viewvc/llvm-project?rev=355276&view=rev
Log:
Reinstate UNSUPPORTED: linux on stop-hook-threads.test

This stanza was removed in r355213, but it seems that patch did not
fully fix the problem, as the test still fails sporadically
(particularly under heavy load) on linux.

Modified:
lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test

Modified: lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test?rev=355276&r1=355275&r2=355276&view=diff
==
--- lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test (original)
+++ lldb/trunk/lit/ExecControl/StopHook/stop-hook-threads.test Sat Mar  2 
11:58:10 2019
@@ -4,6 +4,7 @@
 # RUN: %lldb -b -s %p/Inputs/stop-hook-threads-2.lldbinit -s %s -f %t \
 # RUN: | FileCheck --check-prefix=CHECK --check-prefix=CHECK-FILTER %s
 # XFAIL: system-windows
+# UNSUPPORTED: system-linux
 
 thread list
 break set -f stop-hook-threads.cpp -p "Set break point at this line"


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

[Lldb-commits] [PATCH] D58792: Add "operator bool" to SB APIs

2019-03-02 Thread Pavel Labath via Phabricator via lldb-commits

labath updated this revision to Diff 189057.
labath added a comment.

The version which makes "operator bool" const.


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

https://reviews.llvm.org/D58792

Files:
  include/lldb/API/SBAddress.h
  include/lldb/API/SBBlock.h
  include/lldb/API/SBBreakpoint.h
  include/lldb/API/SBBreakpointLocation.h
  include/lldb/API/SBBreakpointName.h
  include/lldb/API/SBBroadcaster.h
  include/lldb/API/SBCommandInterpreter.h
  include/lldb/API/SBCommandReturnObject.h
  include/lldb/API/SBCommunication.h
  include/lldb/API/SBCompileUnit.h
  include/lldb/API/SBData.h
  include/lldb/API/SBDebugger.h
  include/lldb/API/SBDeclaration.h
  include/lldb/API/SBError.h
  include/lldb/API/SBEvent.h
  include/lldb/API/SBFileSpec.h
  include/lldb/API/SBFrame.h
  include/lldb/API/SBFunction.h
  include/lldb/API/SBInstruction.h
  include/lldb/API/SBInstructionList.h
  include/lldb/API/SBLineEntry.h
  include/lldb/API/SBListener.h
  include/lldb/API/SBModule.h
  include/lldb/API/SBModuleSpec.h
  include/lldb/API/SBPlatform.h
  include/lldb/API/SBProcess.h
  include/lldb/API/SBProcessInfo.h
  include/lldb/API/SBQueue.h
  include/lldb/API/SBQueueItem.h
  include/lldb/API/SBSection.h
  include/lldb/API/SBStream.h
  include/lldb/API/SBStringList.h
  include/lldb/API/SBStructuredData.h
  include/lldb/API/SBSymbol.h
  include/lldb/API/SBSymbolContext.h
  include/lldb/API/SBSymbolContextList.h
  include/lldb/API/SBTarget.h
  include/lldb/API/SBThread.h
  include/lldb/API/SBThreadCollection.h
  include/lldb/API/SBThreadPlan.h
  include/lldb/API/SBTrace.h
  include/lldb/API/SBTraceOptions.h
  include/lldb/API/SBType.h
  include/lldb/API/SBTypeCategory.h
  include/lldb/API/SBTypeEnumMember.h
  include/lldb/API/SBTypeFilter.h
  include/lldb/API/SBTypeFormat.h
  include/lldb/API/SBTypeNameSpecifier.h
  include/lldb/API/SBTypeSummary.h
  include/lldb/API/SBTypeSynthetic.h
  include/lldb/API/SBUnixSignals.h
  include/lldb/API/SBValue.h
  include/lldb/API/SBValueList.h
  include/lldb/API/SBVariablesOptions.h
  include/lldb/API/SBWatchpoint.h
  scripts/Python/modify-python-lldb.py
  scripts/interface/SBAddress.i
  scripts/interface/SBBlock.i
  scripts/interface/SBBreakpoint.i
  scripts/interface/SBBreakpointLocation.i
  scripts/interface/SBBreakpointName.i
  scripts/interface/SBBroadcaster.i
  scripts/interface/SBCommandInterpreter.i
  scripts/interface/SBCommandReturnObject.i
  scripts/interface/SBCommunication.i
  scripts/interface/SBCompileUnit.i
  scripts/interface/SBData.i
  scripts/interface/SBDebugger.i
  scripts/interface/SBDeclaration.i
  scripts/interface/SBError.i
  scripts/interface/SBEvent.i
  scripts/interface/SBFileSpec.i
  scripts/interface/SBFrame.i
  scripts/interface/SBFunction.i
  scripts/interface/SBInstruction.i
  scripts/interface/SBInstructionList.i
  scripts/interface/SBLineEntry.i
  scripts/interface/SBListener.i
  scripts/interface/SBModule.i
  scripts/interface/SBModuleSpec.i
  scripts/interface/SBPlatform.i
  scripts/interface/SBProcess.i
  scripts/interface/SBProcessInfo.i
  scripts/interface/SBQueue.i
  scripts/interface/SBQueueItem.i
  scripts/interface/SBSection.i
  scripts/interface/SBStream.i
  scripts/interface/SBStringList.i
  scripts/interface/SBStructuredData.i
  scripts/interface/SBSymbol.i
  scripts/interface/SBSymbolContext.i
  scripts/interface/SBSymbolContextList.i
  scripts/interface/SBTarget.i
  scripts/interface/SBThread.i
  scripts/interface/SBThreadCollection.i
  scripts/interface/SBThreadPlan.i
  scripts/interface/SBTrace.i
  scripts/interface/SBTraceOptions.i
  scripts/interface/SBType.i
  scripts/interface/SBTypeCategory.i
  scripts/interface/SBTypeEnumMember.i
  scripts/interface/SBTypeFilter.i
  scripts/interface/SBTypeFormat.i
  scripts/interface/SBTypeNameSpecifier.i
  scripts/interface/SBTypeSummary.i
  scripts/interface/SBTypeSynthetic.i
  scripts/interface/SBUnixSignals.i
  scripts/interface/SBValue.i
  scripts/interface/SBValueList.i
  scripts/interface/SBVariablesOptions.i
  scripts/interface/SBWatchpoint.i
  scripts/lldb.swig
  source/API/SBAddress.cpp
  source/API/SBBlock.cpp
  source/API/SBBreakpoint.cpp
  source/API/SBBreakpointLocation.cpp
  source/API/SBBreakpointName.cpp
  source/API/SBBroadcaster.cpp
  source/API/SBCommandInterpreter.cpp
  source/API/SBCommandReturnObject.cpp
  source/API/SBCommunication.cpp
  source/API/SBCompileUnit.cpp
  source/API/SBData.cpp
  source/API/SBDebugger.cpp
  source/API/SBDeclaration.cpp
  source/API/SBError.cpp
  source/API/SBEvent.cpp
  source/API/SBFileSpec.cpp
  source/API/SBFrame.cpp
  source/API/SBFunction.cpp
  source/API/SBInstruction.cpp
  source/API/SBInstructionList.cpp
  source/API/SBLineEntry.cpp
  source/API/SBListener.cpp
  source/API/SBModule.cpp
  source/API/SBModuleSpec.cpp
  source/API/SBPlatform.cpp
  source/API/SBProcess.cpp
  source/API/SBProcessInfo.cpp
  source/API/SBQueue.cpp
  source/API/SBQueueItem.cpp
  source/API/SBSection.cpp
  source/API/SBStream.cpp
  source/A

[Lldb-commits] [PATCH] D58792: Add "operator bool" to SB APIs

2019-03-02 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D58792#1415631 , @clayborg wrote:

> If this is new API I guess it is ok to have them all be const. I was mostly 
> worried that you wouldn't be able to call a non const function from a const 
> function. Do we have any IsValid() calls that are const? I believe we do. If 
> so, how are we calling IsValid() if it is const from a non const conversion 
> operator?

The easiest way to fix that is to invert the calling direction. We can make the 
"operator bool" (which I guess we have agreed we want to be const?) contain the 
"canonical" implementation of the validity check, and then have the IsValid 
function (const or non-const) call into that. Since the bool operator will 
always be const, this will work regardless of whether the IsValid operation is 
declared to be const or not. If we then wanted to, we could make the "IsValid" 
function deprecated and remove it in the hypothetical v2 API.

That latest version of the patch implements that idea (the first part of it, 
the APIv2 thingy is just an idea).

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

https://reviews.llvm.org/D58792

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

[Lldb-commits] [PATCH] D58167: Refactor user/group name resolving code

2019-03-02 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

Greg, I believe I've responded to all your comments. If there is anything else 
you want me to do here, please let me know.


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

https://reviews.llvm.org/D58167



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

[Lldb-commits] [PATCH] D58842: Move ProcessInstanceInfo and similar to Utility

2019-03-02 Thread Pavel Labath via Phabricator via lldb-commits

labath added a comment.

In D58842#1415542 , @zturner wrote:

> In D58842#1415526 , @labath wrote:
>
> > Hmm.. I think I've thought of (or remembered, because I have been thinking 
> > about Utility too) a reason why it might be better to keep these in Host. 
> > ProcessLaunchInfo cannot be trivially moved to Utility (and indeed, in this 
> > patch, you are keeping it in Host), because it contains some references to 
> > Host-specific code (PTY stuff). Now, I am not convinced having the PTY 
> > class be a member of ProcessLaunchInfo is a good thing, but assuming we 
> > don't want to refactor that now, I think it might be better to keep 
> > Process(Launch)Info and friends in the same package (i.e., in Host), at 
> > least until we have a reason to do otherwise.
>
>
> Well, the biggest difference between ProcessAttachInfo / ProcessLaunchInfo 
> and the ones here is that those actually have some non-trivial functionality 
> associated with them.  It might be possible to decouple that functionality 
> from the descriptions themselves, but it didn't seem worth it to me.

I agree it's not a top priority, but I think it would be nice to factor that 
out. The reason for that is that ProcessLaunchInfo is also used to describe 
remote launches, and in this case, having a Host PTY around doesn't make sense 
(we might (and we do) want to have a flag that says a pty should be used on the 
remote side, but an actual host pty object does not make sense there).

> I have a mild preference for putting them in Utility on the grounds that 
> logically that's where they seem to make the most sense.  A Process could 
> just as easily be running on a target as on the host, and we may want to pass 
> this description around, and so favoring one or the other regarding to put 
> them seemed a bit biased.  We do already have a process class in Host called 
> HostProcess, and that's more what I envision a host-specific process looking 
> like.  Low level methods that map directly to system calls to manipulate and 
> query a process's state, etc.

Ok, I am fine with putting this in Utility then (unless someone else speaks up 
about his preference for the location of this). In the future, I am starting to 
think we could have a new package (name TBD) which would contain things that 
"describe some property of a process, but without any bias towards a particular 
implementation of the process (Target, Host, lldb-server, ...)". I will soon 
need to move MemoryRegionInfo out of Utility and into something else, and it 
seems to me this class could fit that description too.

> As for D58167 , I mostly just had a drive-by 
> passing comment, and it looked fine to me after that, but I guess I was 
> waiting for someone else to click Accept since my comment was fairly minor.  
> But I'll go ahead and accept it anyway just to unblock

Ok so it seems it's not clear if I answered all of Greg's comments or not. 
Let's wait to see if he has anything to say until monday. If that patch takes 
longer, then you commit this, and I'll rebase that patch on top of this.

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

https://reviews.llvm.org/D58842

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

[Lldb-commits] [PATCH] D58883: [lldb] [Process/gdb-remote] Use '127.0.0.1' in ConnectLocally()

2019-03-02 Thread Michał Górny via Phabricator via lldb-commits

mgorny created this revision.
mgorny added reviewers: krytarowski, labath, JDevlieghere.
Herald added a subscriber: abidh.
Herald added a project: LLDB.

Use '127.0.0.1' instead of 'localhost' in ConnectLocally() function
as this is the specific address the server is bound to.  Using
'localhost' may involve trying IPv6 first which may accidentally be used
by another service.

While technically it might be interesting to support IPv6 here, it would
need to be supported properly, with the connection copying family
and address from the listening socket, and possibly without relying
on existence of 'localhost' at all.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D58883

Files:
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp


Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1283,7 +1283,7 @@
 
   llvm::SmallString<32> remote_addr;
   llvm::raw_svector_ostream(remote_addr)
-  << "connect://localhost:" << listen_socket.GetLocalPortNumber();
+  << "connect://127.0.0.1:" << listen_socket.GetLocalPortNumber();
 
   std::unique_ptr conn_up(
   new ConnectionFileDescriptor());


Index: lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1283,7 +1283,7 @@
 
   llvm::SmallString<32> remote_addr;
   llvm::raw_svector_ostream(remote_addr)
-  << "connect://localhost:" << listen_socket.GetLocalPortNumber();
+  << "connect://127.0.0.1:" << listen_socket.GetLocalPortNumber();
 
   std::unique_ptr conn_up(
   new ConnectionFileDescriptor());
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58871: [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

[Lldb-commits] [PATCH] D58860: [build.py] Allow clang-cl to build files starting with '/U'

[Lldb-commits] [PATCH] D58871: [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

[Lldb-commits] [lldb] r355270 - Fix gcc build for r355249

[Lldb-commits] [lldb] r355273 - [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

[Lldb-commits] [lldb] r355274 - [lldb] [lit] Pass -pthread on NetBSD as well

[Lldb-commits] [PATCH] D58871: [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSD

[Lldb-commits] [lldb] r355276 - Reinstate UNSUPPORTED: linux on stop-hook-threads.test

[Lldb-commits] [PATCH] D58792: Add "operator bool" to SB APIs

[Lldb-commits] [PATCH] D58792: Add "operator bool" to SB APIs

[Lldb-commits] [PATCH] D58167: Refactor user/group name resolving code

[Lldb-commits] [PATCH] D58842: Move ProcessInstanceInfo and similar to Utility

[Lldb-commits] [PATCH] D58883: [lldb] [Process/gdb-remote] Use '127.0.0.1' in ConnectLocally()

13 matches

Site Navigation

Mail list logo

Footer information