Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

> sleep_for is definitely better than usleep because of portability (and
> we use it elsewhere already).

Okay that is what I went with.
 
> Could you attach the patch to phabricator instead
>  ? It's easier to make
> comments and iterate there. When you upload the patch be sure to
> include full context in it (git diff -U or similar). Or you can
> use the arcanist tool which will do it for you.

I _think_ I have done this correctly.

https://reviews.llvm.org/D47879

$ svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb-trunk
$ patch 0001-First-working-attempt.patch # this is what I mailed last night
$ arc diff

I was not quite sure what I should write for a title or summary. Based on other 
differentials on the site, the title usually seems to have something in 
brackets but it is not clear to me what that should be in my case.

> As for the test, there are two test ways you can do that. One is using
> the python tests
> (test/testcases/tools/lldb-server/TestGdbRemoteAttach.py would be a
> good starting point), other is via googletest
> (unittests/tools/lldb-server/LLGSTest.cpp). Neither of the tests is
> going to be particularly nice because you will have to juggle multiple
> things (speaking with the server and launching the inferior), but it
> should be doable using both.

I will see what I can glean from those examples. See if I can turn them into 
something.

> We should already be able to display a better error message, if the
> server sends one (the Status overload of the SendErrorResponse
> function). If the error string that comes out of that is not good
> enough, then we can tweak whoever creates the Status object to fill it
> out better as a separate patch.

I will look into this and see what is currently happening.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Pavel Labath via lldb-dev]

sleep_for is definitely better than usleep because of portability (and
we use it elsewhere already).

Could you attach the patch to phabricator instead
 ? It's easier to make
comments and iterate there. When you upload the patch be sure to
include full context in it (git diff -U or similar). Or you can
use the arcanist tool which will do it for you.

As for the test, there are two test ways you can do that. One is using
the python tests
(test/testcases/tools/lldb-server/TestGdbRemoteAttach.py would be a
good starting point), other is via googletest
(unittests/tools/lldb-server/LLGSTest.cpp). Neither of the tests is
going to be particularly nice because you will have to juggle multiple
things (speaking with the server and launching the inferior), but it
should be doable using both.

We should already be able to display a better error message, if the
server sends one (the Status overload of the SendErrorResponse
function). If the error string that comes out of that is not good
enough, then we can tweak whoever creates the Status object to fill it
out better as a separate patch.


On Thu, 7 Jun 2018 at 04:23, Ryan Lovelett via lldb-dev
 wrote:
>
> I'm attaching the first cut of the patch that I think is worth sharing for 
> feedback. There is more work to do with regard to documentation and tests. 
> Any feedback is appreciated.
>
> I am going to do my best and follow the steps listed in the "LLVM Developer 
> Policy" as this continues forward.
>
> Greg, Pavel, and Jim thank you very much for the help you have provided thus 
> far. This would have been insurmountable without the guidance.
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

I'm attaching the first cut of the patch that I think is worth sharing for 
feedback. There is more work to do with regard to documentation and tests. Any 
feedback is appreciated.

I am going to do my best and follow the steps listed in the "LLVM Developer 
Policy" as this continues forward.

Greg, Pavel, and Jim thank you very much for the help you have provided thus 
far. This would have been insurmountable without the guidance.
From 765f424beb312e8bf88037efbe35d72b921444bd Mon Sep 17 00:00:00 2001
From: Ryan Lovelett 
Date: Wed, 6 Jun 2018 23:07:14 -0400
Subject: [PATCH] First working attempt

Signed-off-by: Ryan Lovelett 
---
 .../GDBRemoteCommunicationServerLLGS.cpp  | 92 +++
 .../GDBRemoteCommunicationServerLLGS.h| 13 +++
 2 files changed, 105 insertions(+)

diff --git a/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp b/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index 32741c240..8c5b7ea73 100644
--- a/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ b/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -163,6 +163,9 @@ void GDBRemoteCommunicationServerLLGS::RegisterPacketHandlers() {
   RegisterMemberFunctionHandler(
   StringExtractorGDBRemote::eServerPacketType_vAttach,
   &GDBRemoteCommunicationServerLLGS::Handle_vAttach);
+  RegisterMemberFunctionHandler(
+  StringExtractorGDBRemote::eServerPacketType_vAttachWait,
+  &GDBRemoteCommunicationServerLLGS::Handle_vAttachWait);
   RegisterMemberFunctionHandler(
   StringExtractorGDBRemote::eServerPacketType_vCont,
   &GDBRemoteCommunicationServerLLGS::Handle_vCont);
@@ -327,6 +330,62 @@ Status GDBRemoteCommunicationServerLLGS::AttachToProcess(lldb::pid_t pid) {
   return Status();
 }
 
+Status GDBRemoteCommunicationServerLLGS::AttachWaitProcess(
+std::string waitfor_process_name,
+std::chrono::milliseconds waitfor_interval) {
+  Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_PROCESS));
+
+  // Create the matcher used to search the process list
+  ProcessInstanceInfoList exclusion_list;
+  ProcessInstanceInfoMatch match_info;
+  match_info.GetProcessInfo().GetExecutableFile()
+.SetFile(waitfor_process_name, false);
+  match_info.SetNameMatchType(NameMatch::EndsWith);
+
+  // Create the excluded process list before polling begins
+  Host::FindProcesses(match_info, exclusion_list);
+
+  if (log)
+log->Printf("GDBRemoteCommunicationServerLLGS::%s waiting for '%s' "
+"to appear", __FUNCTION__, waitfor_process_name.c_str());
+
+  lldb::pid_t waitfor_pid = LLDB_INVALID_PROCESS_ID;
+  ProcessInstanceInfoList loop_process_list;
+
+  while (waitfor_pid == LLDB_INVALID_PROCESS_ID) {
+loop_process_list.Clear();
+if (Host::FindProcesses(match_info, loop_process_list)) {
+  // The for loop is to checking for the first matching process that was
+  // not in the excluded process list.
+  for(size_t i = 0; i < loop_process_list.GetSize(); i++) {
+waitfor_pid = loop_process_list.GetProcessIDAtIndex(i);
+for(size_t j = 0; j < exclusion_list.GetSize(); j++) {
+  if (exclusion_list.GetProcessIDAtIndex(j) == waitfor_pid) {
+waitfor_pid = LLDB_INVALID_PROCESS_ID;
+  }
+}
+
+// If waitfor_pid is not in our exclusion list then use it
+if (waitfor_pid != LLDB_INVALID_PROCESS_ID) {
+  if (log)
+log->Printf("GDBRemoteCommunicationServerLLGS::%s found pid "
+"%" PRIu64, __FUNCTION__, waitfor_pid);
+  break;
+}
+  }
+}
+// If we have not found the new process sleep until next poll.
+if (waitfor_pid == LLDB_INVALID_PROCESS_ID) {
+  if (log)
+log->Printf("GDBRemoteCommunicationServerLLGS::%s sleep "
+"%" PRIu64, __FUNCTION__, waitfor_interval);
+  std::this_thread::sleep_for(waitfor_interval);
+}
+  }
+
+  return AttachToProcess(waitfor_pid);
+}
+
 void GDBRemoteCommunicationServerLLGS::InitializeDelegate(
 NativeProcessProtocol *process) {
   assert(process && "process cannot be NULL");
@@ -2942,6 +3001,39 @@ GDBRemoteCommunicationServerLLGS::Handle_vAttach(
   return SendStopReasonForState(m_debugged_process_up->GetState());
 }
 
+GDBRemoteCommunication::PacketResult
+GDBRemoteCommunicationServerLLGS::Handle_vAttachWait(
+StringExtractorGDBRemote &packet) {
+  Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_PROCESS));
+
+  // Consume the ';' after vAttach.
+  packet.SetFilePos(strlen("vAttachWait"));
+  if (!packet.GetBytesLeft() || packet.GetChar() != ';')
+return SendIllFormedResponse(packet, "vAttachWait missing expected ';'");
+
+  // Allocate the buffer for the process name from vAttachWait
+  std::string process_name;
+  if (!packet.GetHexByteString(process_name))
+return SendIllFormedResponse(packet,
+ "vAttachWait failed to parse process name");
+
+

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

> Sleep is used to make the system sleep the current thread a little bit 
> between polling for processes by name. If the sleep isn't there, we will 
> light up a CPU with really quick polling for the processes by name, so 
> we should use usleep() which take a sleep amount in microseconds to not 
> peg the CPU at 100% while waiting.

Are there any objections to using std::this_thread::sleep_for? The headers seem 
to already be included and other tools inside the project seem to make use of 
it.

Another "issue" I've encountered is related to Ubuntu's ptrace protection [1]. 
If ptrace is blocked for non-child processes then you get an error. In lldb 
you'd see "error: attach failed: lost connection" but in the logs of the 
lldb-server you'd see "GDBRemoteCommunicationServerLLGS::Handle_vAttachWait 
failed to attach to process named langserver-swift: Operation not permitted". 
Of note is the "Operation not permitted".

While I'm still not sure how to check for the presence of the ptrace protection 
(so that a more detailed error can be provided). I think displaying "operation 
not permitted" is more indicative of the underlying error than "lost 
connection". So here's the question: is there a way that I could go about 
surfacing that error back to main lldb?

[1] 
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Greg Clayton via lldb-dev]

> On Jun 6, 2018, at 2:20 PM, Ryan Lovelett  wrote:
> 
> Huzzah! I have a working proof of concept.
> 
> A few more questions (I hope I'm not wearing out my welcome):

We are very happy to see this feature coming along, so no worries. Ask as many 
questions as you need!

> 
> 1. There seems to be a "sleep" capability in the DNBProcessAttachWait method 
> [1]. I'm not exactly sure how this "sleep" function works. When I use it the 
> sleep seems to be a no-op. Is there another function that should be used for 
> Linux?

Sleep is used to make the system sleep the current thread a little bit between 
polling for processes by name. If the sleep isn't there, we will light up a CPU 
with really quick polling for the processes by name, so we should use usleep() 
which take a sleep amount in microseconds to not peg the CPU at 100% while 
waiting.

> 
> 2. DNBProcessAttachWait seems to have a timeout capability [2]. As far as I 
> can tell, the argument timeout_abstime is hard-coded as NULL. Thus rendering 
> that timer/timeout dead code.  Should replicate that in the Linux code as 
> well?

No need for now.

> 
> 3. Are there, or are there expected to be, tests for this stuff?

Yes! There are many lldb-server tests already. Pavel should be able to direct 
you to how and where to make these tests.

> 
> [1] 
> https://github.com/llvm-mirror/lldb/blob/b64ab3f60c8faa43841af88b10dbcbfd073a82ea/tools/debugserver/source/DNB.cpp#L743
> [2] 
> https://github.com/llvm-mirror/lldb/blob/b64ab3f60c8faa43841af88b10dbcbfd073a82ea/tools/debugserver/source/DNB.cpp#L720-L729
> 
> On Wed, Jun 6, 2018, at 10:38 AM, Pavel Labath wrote:
>> There are other options available as well, but for this particular
>> scenario, I'd go with the following:
>> - start debugging the client, set a breakpoint just before it sends
>> the vAttach packet
>> - when the client reaches this breakpoint, attach a debugger to the
>> server (it will already be running at this point)
>> - let the client send the packet
>> - step through the server as it processes it
>> 
>> That's if you want an interactive debug session. If you just want to
>> see the logs, it should be sufficient to set LLDB_DEBUGSERVER_LOG_FILE
>> and LLDB_SERVER_LOG_CHANNELS environment variables before starting
>> lldb.
>> 
>> On Wed, 6 Jun 2018 at 13:59, Ryan Lovelett  wrote:
>>> 
>>> Does anyone have any specific suggestions on how I might go about 
>>> debugging/testing this? Specifically, turning on the logging in the 
>>> gdb-server and also launching lldb-server separate from lldb so that I can 
>>> actually attach a debugger to it.
>>> 
>>> My workflow right now is to start the gdb-server like so:
>>> 
>>> $ lldb-server gdb-server --log-file /tmp/gdb-server.txt *:1234
>>> 
>>> Then connect the main lldb process like this:
>>> 
>>> $ lldb
>>> (lldb) platform select remote-gdb-server
>>> (lldb) platform connect connect://localhost:1234
>> 
>> This won't work. You are starting up a "gdb-server" instance of
>> lldb-server and then connecting to it as if it was a platform
>> instance. For "local" debugging you don't need that. You only need to
>> mess with the platform when doing "true" remote debugging  That's
>> probably why the latter attempt to attach fails with a weird error.

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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

Huzzah! I have a working proof of concept.

A few more questions (I hope I'm not wearing out my welcome):

1. There seems to be a "sleep" capability in the DNBProcessAttachWait method 
[1]. I'm not exactly sure how this "sleep" function works. When I use it the 
sleep seems to be a no-op. Is there another function that should be used for 
Linux?

2. DNBProcessAttachWait seems to have a timeout capability [2]. As far as I can 
tell, the argument timeout_abstime is hard-coded as NULL. Thus rendering that 
timer/timeout dead code.  Should replicate that in the Linux code as well?

3. Are there, or are there expected to be, tests for this stuff?

[1] 
https://github.com/llvm-mirror/lldb/blob/b64ab3f60c8faa43841af88b10dbcbfd073a82ea/tools/debugserver/source/DNB.cpp#L743
[2] 
https://github.com/llvm-mirror/lldb/blob/b64ab3f60c8faa43841af88b10dbcbfd073a82ea/tools/debugserver/source/DNB.cpp#L720-L729

On Wed, Jun 6, 2018, at 10:38 AM, Pavel Labath wrote:
> There are other options available as well, but for this particular
> scenario, I'd go with the following:
> - start debugging the client, set a breakpoint just before it sends
> the vAttach packet
> - when the client reaches this breakpoint, attach a debugger to the
> server (it will already be running at this point)
> - let the client send the packet
> - step through the server as it processes it
> 
> That's if you want an interactive debug session. If you just want to
> see the logs, it should be sufficient to set LLDB_DEBUGSERVER_LOG_FILE
> and LLDB_SERVER_LOG_CHANNELS environment variables before starting
> lldb.
> 
> On Wed, 6 Jun 2018 at 13:59, Ryan Lovelett  wrote:
> >
> > Does anyone have any specific suggestions on how I might go about 
> > debugging/testing this? Specifically, turning on the logging in the 
> > gdb-server and also launching lldb-server separate from lldb so that I can 
> > actually attach a debugger to it.
> >
> > My workflow right now is to start the gdb-server like so:
> >
> > $ lldb-server gdb-server --log-file /tmp/gdb-server.txt *:1234
> >
> > Then connect the main lldb process like this:
> >
> > $ lldb
> > (lldb) platform select remote-gdb-server
> > (lldb) platform connect connect://localhost:1234
> 
> This won't work. You are starting up a "gdb-server" instance of
> lldb-server and then connecting to it as if it was a platform
> instance. For "local" debugging you don't need that. You only need to
> mess with the platform when doing "true" remote debugging  That's
> probably why the latter attempt to attach fails with a weird error.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Pavel Labath via lldb-dev]

There are other options available as well, but for this particular
scenario, I'd go with the following:
- start debugging the client, set a breakpoint just before it sends
the vAttach packet
- when the client reaches this breakpoint, attach a debugger to the
server (it will already be running at this point)
- let the client send the packet
- step through the server as it processes it

That's if you want an interactive debug session. If you just want to
see the logs, it should be sufficient to set LLDB_DEBUGSERVER_LOG_FILE
and LLDB_SERVER_LOG_CHANNELS environment variables before starting
lldb.

On Wed, 6 Jun 2018 at 13:59, Ryan Lovelett  wrote:
>
> Does anyone have any specific suggestions on how I might go about 
> debugging/testing this? Specifically, turning on the logging in the 
> gdb-server and also launching lldb-server separate from lldb so that I can 
> actually attach a debugger to it.
>
> My workflow right now is to start the gdb-server like so:
>
> $ lldb-server gdb-server --log-file /tmp/gdb-server.txt *:1234
>
> Then connect the main lldb process like this:
>
> $ lldb
> (lldb) platform select remote-gdb-server
> (lldb) platform connect connect://localhost:1234

This won't work. You are starting up a "gdb-server" instance of
lldb-server and then connecting to it as if it was a platform
instance. For "local" debugging you don't need that. You only need to
mess with the platform when doing "true" remote debugging  That's
probably why the latter attempt to attach fails with a weird error.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

Does anyone have any specific suggestions on how I might go about 
debugging/testing this? Specifically, turning on the logging in the gdb-server 
and also launching lldb-server separate from lldb so that I can actually attach 
a debugger to it.

My workflow right now is to start the gdb-server like so:

$ lldb-server gdb-server --log-file /tmp/gdb-server.txt *:1234

Then connect the main lldb process like this:

$ lldb
(lldb) platform select remote-gdb-server
(lldb) platform connect connect://localhost:1234

As far as I can tell, that seems to be working I get a message in gdb-server 
"lldb-server-local_buildConnection established."

Unfortunately, when I issue my command,

(lldb) process attach --name "langserver-swift" --waitfor
error: attach failed: invalid host:port specification: 'localhost'

The log file remains zero length.

I presume this means I am incorrectly launching my gdb-server both with respect 
to the logging and how I tell lldb to connect to it. Though it is not clear to 
me what I should do differently. The commands I've got I pieced together from 
an article on lldb.llvm.org titled "Remote debugging with LLDB" [1].

[1] https://lldb.llvm.org/remote.html

On Wed, Jun 6, 2018, at 3:59 AM, Pavel Labath wrote:
> There is some documentation on the packets in docs/lldb-gdb-remote.txt
> in the lldb repo, though for this particular packet it does not say
> much about the encoding (patches welcome).
> 
> That said, it looks like the format is just that we send the process
> name hex-encoded. For that you can simply use
> StringExtractor.GetHexBytes. There should be plenty of examples doing
> hex {en|de}coding around the codebase.
> On Wed, 6 Jun 2018 at 03:51, Ryan Lovelett via lldb-dev
>  wrote:
> >
> > Thank you that was a huge help.  I'm making some progress now.
> >
> > Though I wonder, is there any documentation of the GDB packet format? The 
> > reason I ask is that I'm trying to figure out to get the process name from 
> > vAttach.
> >
> > I've looked at how debugserver does it, namely the method 
> > GetProcessNameFrom_vAttach [1], and I cannot seem to find the equivalent 
> > method in StringExtractorGDBRemote or StringExtractor (though I'll admit 
> > that it might be obvious and I'm just missing it). If that's the case I 
> > imagine I'll have to implement it and I would like to at least understand 
> > the packet format to do that.
> >
> > [1] 
> > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/tools/debugserver/source/RNBRemote.cpp#L3585
> >
> > On Tue, Jun 5, 2018, at 9:03 PM, Jim Ingham wrote:
> > > Except for Windows and FreeBSD, lldb uses a server program to do the
> > > actual debugging - either debugserver on Darwin or lldb-server
> > > elsewhere.  The interface to these servers (and to the in-process
> > > debugging in Windows & FreeBSD) is abstracted being Process Plugins,
> > > which the generic code uses.  Target::Attach is in generic code, it
> > > won't know anything about the actual method used to attach, wait for
> > > attach, whatever.  That will be dispatched to the currently active
> > > ProcessPlugin.
> > >
> > > ProcessGDBRemote is the plugin that is used on Linux & Darwin.  It is
> > > the code that actually talks to debugserver or lldb-rpc-server from
> > > within lldb.  And that's the code in lldb that sends the vAttachWait
> > > gdb-remote protocol packet to instruct the above-mentioned servers to
> > > implement attach-wait.  That request works on Darwin because debugserver
> > > handles the vAttachWait packet, but doesn't work on Linux because lldb-
> > > rpc-server doesn't know currently respond to the vAttachWait packet.  So
> > > all you should need to do is teach lldb-server to handle the vAttachWait
> > > packet.
> > >
> > > Jim
> > >
> > >
> > > > On Jun 5, 2018, at 5:44 PM, Ryan Lovelett via lldb-dev 
> > > >  wrote:
> > > >
> > > > I think I might be a little lost. I built a lldb in debug mode and I am 
> > > > running lldb in an lldb debugger (very meta).
> > > >
> > > > Earlier in the thread you said "we need a better error message when 
> > > > vAttachWait returns unsupported" I have found where the error message, 
> > > > e.g., "error: attach failed: lost connection" is constructed. The 
> > > > "attach failed: " comes from here [1] and the "lost connection" comes 
> > > > from here [2].
> > > >
> > > > What do you mean by "vAttachWait"? Am I missing something obvious?
> > > >
> > > > It seems like you are expecting lldb-server to be the place where the 
> > > > fix will be implemented. Though in the debugger I'm seeing the method 
> > > > Target::Attach() [3] as the place where the connection attempt is made 
> > > > and fails.
> > > >
> > > > [1] 
> > > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518
> > > > [2] 
> > > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

Thank you. That get me moving again. I will also see if there is anything I 
could contribute to lldb-gdb-remote.txt regarding the format of this packet.

On Wed, Jun 6, 2018, at 3:59 AM, Pavel Labath wrote:
> There is some documentation on the packets in docs/lldb-gdb-remote.txt
> in the lldb repo, though for this particular packet it does not say
> much about the encoding (patches welcome).
> 
> That said, it looks like the format is just that we send the process
> name hex-encoded. For that you can simply use
> StringExtractor.GetHexBytes. There should be plenty of examples doing
> hex {en|de}coding around the codebase.
> On Wed, 6 Jun 2018 at 03:51, Ryan Lovelett via lldb-dev
>  wrote:
> >
> > Thank you that was a huge help.  I'm making some progress now.
> >
> > Though I wonder, is there any documentation of the GDB packet format? The 
> > reason I ask is that I'm trying to figure out to get the process name from 
> > vAttach.
> >
> > I've looked at how debugserver does it, namely the method 
> > GetProcessNameFrom_vAttach [1], and I cannot seem to find the equivalent 
> > method in StringExtractorGDBRemote or StringExtractor (though I'll admit 
> > that it might be obvious and I'm just missing it). If that's the case I 
> > imagine I'll have to implement it and I would like to at least understand 
> > the packet format to do that.
> >
> > [1] 
> > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/tools/debugserver/source/RNBRemote.cpp#L3585
> >
> > On Tue, Jun 5, 2018, at 9:03 PM, Jim Ingham wrote:
> > > Except for Windows and FreeBSD, lldb uses a server program to do the
> > > actual debugging - either debugserver on Darwin or lldb-server
> > > elsewhere.  The interface to these servers (and to the in-process
> > > debugging in Windows & FreeBSD) is abstracted being Process Plugins,
> > > which the generic code uses.  Target::Attach is in generic code, it
> > > won't know anything about the actual method used to attach, wait for
> > > attach, whatever.  That will be dispatched to the currently active
> > > ProcessPlugin.
> > >
> > > ProcessGDBRemote is the plugin that is used on Linux & Darwin.  It is
> > > the code that actually talks to debugserver or lldb-rpc-server from
> > > within lldb.  And that's the code in lldb that sends the vAttachWait
> > > gdb-remote protocol packet to instruct the above-mentioned servers to
> > > implement attach-wait.  That request works on Darwin because debugserver
> > > handles the vAttachWait packet, but doesn't work on Linux because lldb-
> > > rpc-server doesn't know currently respond to the vAttachWait packet.  So
> > > all you should need to do is teach lldb-server to handle the vAttachWait
> > > packet.
> > >
> > > Jim
> > >
> > >
> > > > On Jun 5, 2018, at 5:44 PM, Ryan Lovelett via lldb-dev 
> > > >  wrote:
> > > >
> > > > I think I might be a little lost. I built a lldb in debug mode and I am 
> > > > running lldb in an lldb debugger (very meta).
> > > >
> > > > Earlier in the thread you said "we need a better error message when 
> > > > vAttachWait returns unsupported" I have found where the error message, 
> > > > e.g., "error: attach failed: lost connection" is constructed. The 
> > > > "attach failed: " comes from here [1] and the "lost connection" comes 
> > > > from here [2].
> > > >
> > > > What do you mean by "vAttachWait"? Am I missing something obvious?
> > > >
> > > > It seems like you are expecting lldb-server to be the place where the 
> > > > fix will be implemented. Though in the debugger I'm seeing the method 
> > > > Target::Attach() [3] as the place where the connection attempt is made 
> > > > and fails.
> > > >
> > > > [1] 
> > > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518
> > > > [2] 
> > > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445
> > > > [3] 
> > > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374
> > > >
> > > > On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
> > > >> I will be too busy this week to get to this, so please do have a stab 
> > > >> at it.
> > > >>
> > > >> Basically the flow that debug server does is:
> > > >> 1 - get a list of all processes whose basename matches and remember 
> > > >> those pids so we don't try to attach to them since we are waiting for 
> > > >> a new process to show up
> > > >> 2 - poll the OS for the process list and wait for a new pid to show up 
> > > >> with the basename and attach to the first one that matches whose pid 
> > > >> isn't i the list from step #1
> > > >>
> > > >> On MacOSX we don't have a way to be notified of new processes are 
> > > >> spawned, not sure on other unix variants. If it is possible, we would 
> > > >> want change to:
> > > >> 1 - sign up to be notified about new processes
> > > >> 2 - as each process 

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Pavel Labath via lldb-dev]

There is some documentation on the packets in docs/lldb-gdb-remote.txt
in the lldb repo, though for this particular packet it does not say
much about the encoding (patches welcome).

That said, it looks like the format is just that we send the process
name hex-encoded. For that you can simply use
StringExtractor.GetHexBytes. There should be plenty of examples doing
hex {en|de}coding around the codebase.
On Wed, 6 Jun 2018 at 03:51, Ryan Lovelett via lldb-dev
 wrote:
>
> Thank you that was a huge help.  I'm making some progress now.
>
> Though I wonder, is there any documentation of the GDB packet format? The 
> reason I ask is that I'm trying to figure out to get the process name from 
> vAttach.
>
> I've looked at how debugserver does it, namely the method 
> GetProcessNameFrom_vAttach [1], and I cannot seem to find the equivalent 
> method in StringExtractorGDBRemote or StringExtractor (though I'll admit that 
> it might be obvious and I'm just missing it). If that's the case I imagine 
> I'll have to implement it and I would like to at least understand the packet 
> format to do that.
>
> [1] 
> https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/tools/debugserver/source/RNBRemote.cpp#L3585
>
> On Tue, Jun 5, 2018, at 9:03 PM, Jim Ingham wrote:
> > Except for Windows and FreeBSD, lldb uses a server program to do the
> > actual debugging - either debugserver on Darwin or lldb-server
> > elsewhere.  The interface to these servers (and to the in-process
> > debugging in Windows & FreeBSD) is abstracted being Process Plugins,
> > which the generic code uses.  Target::Attach is in generic code, it
> > won't know anything about the actual method used to attach, wait for
> > attach, whatever.  That will be dispatched to the currently active
> > ProcessPlugin.
> >
> > ProcessGDBRemote is the plugin that is used on Linux & Darwin.  It is
> > the code that actually talks to debugserver or lldb-rpc-server from
> > within lldb.  And that's the code in lldb that sends the vAttachWait
> > gdb-remote protocol packet to instruct the above-mentioned servers to
> > implement attach-wait.  That request works on Darwin because debugserver
> > handles the vAttachWait packet, but doesn't work on Linux because lldb-
> > rpc-server doesn't know currently respond to the vAttachWait packet.  So
> > all you should need to do is teach lldb-server to handle the vAttachWait
> > packet.
> >
> > Jim
> >
> >
> > > On Jun 5, 2018, at 5:44 PM, Ryan Lovelett via lldb-dev 
> > >  wrote:
> > >
> > > I think I might be a little lost. I built a lldb in debug mode and I am 
> > > running lldb in an lldb debugger (very meta).
> > >
> > > Earlier in the thread you said "we need a better error message when 
> > > vAttachWait returns unsupported" I have found where the error message, 
> > > e.g., "error: attach failed: lost connection" is constructed. The "attach 
> > > failed: " comes from here [1] and the "lost connection" comes from here 
> > > [2].
> > >
> > > What do you mean by "vAttachWait"? Am I missing something obvious?
> > >
> > > It seems like you are expecting lldb-server to be the place where the fix 
> > > will be implemented. Though in the debugger I'm seeing the method 
> > > Target::Attach() [3] as the place where the connection attempt is made 
> > > and fails.
> > >
> > > [1] 
> > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518
> > > [2] 
> > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445
> > > [3] 
> > > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374
> > >
> > > On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
> > >> I will be too busy this week to get to this, so please do have a stab at 
> > >> it.
> > >>
> > >> Basically the flow that debug server does is:
> > >> 1 - get a list of all processes whose basename matches and remember 
> > >> those pids so we don't try to attach to them since we are waiting for a 
> > >> new process to show up
> > >> 2 - poll the OS for the process list and wait for a new pid to show up 
> > >> with the basename and attach to the first one that matches whose pid 
> > >> isn't i the list from step #1
> > >>
> > >> On MacOSX we don't have a way to be notified of new processes are 
> > >> spawned, not sure on other unix variants. If it is possible, we would 
> > >> want change to:
> > >> 1 - sign up to be notified about new processes
> > >> 2 - as each process gets launched, check for a match and attach as 
> > >> quickly as possible
> > >>
> > >> Hope this helps and I look forward to seeing your patch!
> > >>
> > >> Greg
> > >>
> > >>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett  wrote:
> > >>>
> > >>> Greg,
> > >>>
> > >>> Is there anything I can do to help you implement or test this feature? 
> > >>> Obviously I'm willing to roll-up my sleeves an

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

Thank you that was a huge help.  I'm making some progress now.

Though I wonder, is there any documentation of the GDB packet format? The 
reason I ask is that I'm trying to figure out to get the process name from 
vAttach.

I've looked at how debugserver does it, namely the method 
GetProcessNameFrom_vAttach [1], and I cannot seem to find the equivalent method 
in StringExtractorGDBRemote or StringExtractor (though I'll admit that it might 
be obvious and I'm just missing it). If that's the case I imagine I'll have to 
implement it and I would like to at least understand the packet format to do 
that.

[1] 
https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/tools/debugserver/source/RNBRemote.cpp#L3585

On Tue, Jun 5, 2018, at 9:03 PM, Jim Ingham wrote:
> Except for Windows and FreeBSD, lldb uses a server program to do the 
> actual debugging - either debugserver on Darwin or lldb-server 
> elsewhere.  The interface to these servers (and to the in-process 
> debugging in Windows & FreeBSD) is abstracted being Process Plugins, 
> which the generic code uses.  Target::Attach is in generic code, it 
> won't know anything about the actual method used to attach, wait for 
> attach, whatever.  That will be dispatched to the currently active 
> ProcessPlugin.
> 
> ProcessGDBRemote is the plugin that is used on Linux & Darwin.  It is 
> the code that actually talks to debugserver or lldb-rpc-server from 
> within lldb.  And that's the code in lldb that sends the vAttachWait 
> gdb-remote protocol packet to instruct the above-mentioned servers to 
> implement attach-wait.  That request works on Darwin because debugserver 
> handles the vAttachWait packet, but doesn't work on Linux because lldb-
> rpc-server doesn't know currently respond to the vAttachWait packet.  So 
> all you should need to do is teach lldb-server to handle the vAttachWait 
> packet.
> 
> Jim
>   
> 
> > On Jun 5, 2018, at 5:44 PM, Ryan Lovelett via lldb-dev 
> >  wrote:
> > 
> > I think I might be a little lost. I built a lldb in debug mode and I am 
> > running lldb in an lldb debugger (very meta).
> > 
> > Earlier in the thread you said "we need a better error message when 
> > vAttachWait returns unsupported" I have found where the error message, 
> > e.g., "error: attach failed: lost connection" is constructed. The "attach 
> > failed: " comes from here [1] and the "lost connection" comes from here [2].
> > 
> > What do you mean by "vAttachWait"? Am I missing something obvious?
> > 
> > It seems like you are expecting lldb-server to be the place where the fix 
> > will be implemented. Though in the debugger I'm seeing the method 
> > Target::Attach() [3] as the place where the connection attempt is made and 
> > fails.
> > 
> > [1] 
> > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518
> > [2] 
> > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445
> > [3] 
> > https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374
> > 
> > On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
> >> I will be too busy this week to get to this, so please do have a stab at 
> >> it.
> >> 
> >> Basically the flow that debug server does is:
> >> 1 - get a list of all processes whose basename matches and remember those 
> >> pids so we don't try to attach to them since we are waiting for a new 
> >> process to show up
> >> 2 - poll the OS for the process list and wait for a new pid to show up 
> >> with the basename and attach to the first one that matches whose pid isn't 
> >> i the list from step #1
> >> 
> >> On MacOSX we don't have a way to be notified of new processes are spawned, 
> >> not sure on other unix variants. If it is possible, we would want change 
> >> to:
> >> 1 - sign up to be notified about new processes
> >> 2 - as each process gets launched, check for a match and attach as quickly 
> >> as possible
> >> 
> >> Hope this helps and I look forward to seeing your patch!
> >> 
> >> Greg
> >> 
> >>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett  wrote:
> >>> 
> >>> Greg,
> >>> 
> >>> Is there anything I can do to help you implement or test this feature? 
> >>> Obviously I'm willing to roll-up my sleeves and work on this myself too 
> >>> if you've become more busy than you expected. That happens to us all and 
> >>> I completely understand.
> >>> 
> >>> Not being able to debug in this manner is blocking me from adding Linux 
> >>> support to a Swift program. As you might imagine, I'm a little antsy to 
> >>> get past this so I can start writing some code. 
> >>> 
> >>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
>  
>  
> > On May 31, 2018, at 12:40 PM, Ryan Lovelett  wrote:
> > 
> > Well at least there is a little good news. I understood way more of 
> > those logs than I thought I did.
>

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Jim Ingham via lldb-dev]

Except for Windows and FreeBSD, lldb uses a server program to do the actual 
debugging - either debugserver on Darwin or lldb-server elsewhere.  The 
interface to these servers (and to the in-process debugging in Windows & 
FreeBSD) is abstracted being Process Plugins, which the generic code uses.  
Target::Attach is in generic code, it won't know anything about the actual 
method used to attach, wait for attach, whatever.  That will be dispatched to 
the currently active ProcessPlugin.

ProcessGDBRemote is the plugin that is used on Linux & Darwin.  It is the code 
that actually talks to debugserver or lldb-rpc-server from within lldb.  And 
that's the code in lldb that sends the vAttachWait gdb-remote protocol packet 
to instruct the above-mentioned servers to implement attach-wait.  That request 
works on Darwin because debugserver handles the vAttachWait packet, but doesn't 
work on Linux because lldb-rpc-server doesn't know currently respond to the 
vAttachWait packet.  So all you should need to do is teach lldb-server to 
handle the vAttachWait packet.

Jim
  

> On Jun 5, 2018, at 5:44 PM, Ryan Lovelett via lldb-dev 
>  wrote:
> 
> I think I might be a little lost. I built a lldb in debug mode and I am 
> running lldb in an lldb debugger (very meta).
> 
> Earlier in the thread you said "we need a better error message when 
> vAttachWait returns unsupported" I have found where the error message, e.g., 
> "error: attach failed: lost connection" is constructed. The "attach failed: " 
> comes from here [1] and the "lost connection" comes from here [2].
> 
> What do you mean by "vAttachWait"? Am I missing something obvious?
> 
> It seems like you are expecting lldb-server to be the place where the fix 
> will be implemented. Though in the debugger I'm seeing the method 
> Target::Attach() [3] as the place where the connection attempt is made and 
> fails.
> 
> [1] 
> https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518
> [2] 
> https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445
> [3] 
> https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374
> 
> On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
>> I will be too busy this week to get to this, so please do have a stab at it.
>> 
>> Basically the flow that debug server does is:
>> 1 - get a list of all processes whose basename matches and remember those 
>> pids so we don't try to attach to them since we are waiting for a new 
>> process to show up
>> 2 - poll the OS for the process list and wait for a new pid to show up with 
>> the basename and attach to the first one that matches whose pid isn't i the 
>> list from step #1
>> 
>> On MacOSX we don't have a way to be notified of new processes are spawned, 
>> not sure on other unix variants. If it is possible, we would want change to:
>> 1 - sign up to be notified about new processes
>> 2 - as each process gets launched, check for a match and attach as quickly 
>> as possible
>> 
>> Hope this helps and I look forward to seeing your patch!
>> 
>> Greg
>> 
>>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett  wrote:
>>> 
>>> Greg,
>>> 
>>> Is there anything I can do to help you implement or test this feature? 
>>> Obviously I'm willing to roll-up my sleeves and work on this myself too if 
>>> you've become more busy than you expected. That happens to us all and I 
>>> completely understand.
>>> 
>>> Not being able to debug in this manner is blocking me from adding Linux 
>>> support to a Swift program. As you might imagine, I'm a little antsy to get 
>>> past this so I can start writing some code. 
>>> 
>>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
 
 
> On May 31, 2018, at 12:40 PM, Ryan Lovelett  wrote:
> 
> Well at least there is a little good news. I understood way more of those 
> logs than I thought I did.
> 
>> So two issues here:
>> 1 - we need a better error message when vAttachWait returns unsupported
>> 2 - fix lldb-server to support vAttachWait
> 
> A few questions.
> 
> What is the protocol here? Can/should I report the issues at 
> https://bugs.llvm.org/ ? Or is that something that a project member needs 
> to do? Assuming that I can, would this be two seperate issues or one 
> "large" issue?
> 
> Barring that this is not something someone else might implement 
> better/faster than me. Considering I have zero LLDB development 
> experience is this something that I could tackle?
 
 I didn't realize this functionality was missing in lldb-server. I can take 
 a stab at implementing it and see what I can do. Stay tuned.
 
> 
> On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
>> lldb-server claims it doesn't support it:
>> 
>> lldb <  48> send packet: 
>> 

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

I think I might be a little lost. I built a lldb in debug mode and I am
running lldb in an lldb debugger (very meta).
Earlier in the thread you said "we need a better error message when
vAttachWait returns unsupported" I have found where the error message,
e.g., "error: attach failed: lost connection" is constructed. The
"attach failed: " comes from here [1] and the "lost connection" comes
from here [2].
What do you mean by "vAttachWait"? Am I missing something obvious?

It seems like you are expecting lldb-server to be the place where the
fix will be implemented. Though in the debugger I'm seeing the method
Target::Attach() [3] as the place where the connection attempt is made
and fails.
[1] 
https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Commands/CommandObjectProcess.cpp#L518[2]
 
https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3444-L3445[3]
 
https://github.com/apple/swift-lldb/blob/a8c149f75a8cba674bead048cd9c80ddc8166a8a/source/Target/Target.cpp#L3374
On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
> I will be too busy this week to get to this, so please do have a
> stab at it.> 
> Basically the flow that debug server does is:
> 1 - get a list of all processes whose basename matches and remember
> those pids so we don't try to attach to them since we are waiting for
> a new process to show up> 2 - poll the OS for the process list and wait for a 
> new pid to show up
> with the basename and attach to the first one that matches whose pid
> isn't i the list from step #1> 
> On MacOSX we don't have a way to be notified of new processes are
> spawned, not sure on other unix variants. If it is possible, we would
> want change to:> 1 - sign up to be notified about new processes
> 2 - as each process gets launched, check for a match and attach as
> quickly as possible> 
> Hope this helps and I look forward to seeing your patch!
> 
> Greg
> 
>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett  wrote:
>> 
>> Greg,
>> 
>> Is there anything I can do to help you implement or test this
>> feature? Obviously I'm willing to roll-up my sleeves and work on this
>> myself too if you've become more busy than you expected. That happens
>> to us all and I completely understand.>> 
>> Not being able to debug in this manner is blocking me from adding
>> Linux support to a Swift program. As you might imagine, I'm a little
>> antsy to get past this so I can start writing some code.>> 
>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
>>> 
>>> 
 On May 31, 2018, at 12:40 PM, Ryan Lovelett 
 wrote: 
 Well at least there is a little good news. I understood way more of
 those logs than I thought I did. 
> So two issues here:
> 1 - we need a better error message when vAttachWait returns
> unsupported> 2 - fix lldb-server to support vAttachWait
 
 A few questions.
 
 What is the protocol here? Can/should I report the issues at
 https://bugs.llvm.org/ ? Or is that something that a project member
 needs to do? Assuming that I can, would this be two seperate issues
 or one "large" issue? 
 Barring that this is not something someone else might implement
 better/faster than me. Considering I have zero LLDB development
 experience is this something that I could tackle?>>> 
>>> I didn't realize this functionality was missing in lldb-server. I
>>> can take a stab at implementing it and see what I can do. Stay
>>> tuned.>>> 
 
 On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
> lldb-server claims it doesn't support it:
> 
> lldb <  48> send packet:
> $vAttachWait;6c616e677365727665722d7377696674#d6> lldb <  
>  4> read packet: $#00
> 
> 
> Returning the empty packet ("$#00") means it is not supported, but
> we really should give a better error message than this.> 
> It isn't that hard to implement. It would be easy to copy the code
> that is in debugserver in DNB.cpp in the DNBProcessAttachWait
> function. Most of it is probably posix style stuff.> 
> So two issues here:
> 1 - we need a better error message when vAttachWait returns
> unsupported> 2 - fix lldb-server to support vAttachWait
> 
> Greg
> 
> 
>> On May 31, 2018, at 11:04 AM, Ryan Lovelett 
>> wrote:>> 
>>> It might be a lldb-server issue?
>> 
>> How would one go about determining this?
>> 
>> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
>> (lldb) process attach --name "" --waitfor
>> error: attach failed: lost connection
>> 
>> Attached the log output. Maybe it'll make more sense to you than
>> me.>> 
>> That escalated quickly. So I've read through that log. I found
>> something that says $qVAttachOrWaitSupported#38 with the
>> following response being $#00. Perhaps I'm reading too much

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Pavel Labath via lldb-dev]

On Tue, 5 Jun 2018 at 01:18, Ryan Lovelett via lldb-dev
 wrote:
>
> So I've found a capability on Linux to be notified about new processes. I 
> have an example of listening for these new processes running on my machine 
> now [1] and I can see when my desired user process spawns. Though 
> documentation on the API is scarce. It also requires that the executable or 
> user have the CAP_NET_ADMIN capability to run.
>
> It's possible that the addition of this requirement is a non-starter. Though 
> I'm not 100% sure. Do you have any thoughts before I pursue this further?

I doubt anybody will be installing lldb with elevated privileges, and
I would be wary of recommending that. Theoretically, we could
implement that approach and use it in case the user happens to have
that privilege, but I don't believe it's worth it. I think we should
just stick to the polling approach. You should be able to get a list
of running processes with `Host::FindProcesses`.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

So I've found a capability on Linux to be notified about new processes.
I have an example of listening for these new processes running on my
machine now [1] and I can see when my desired user process spawns.
Though documentation on the API is scarce. It also requires that the
executable or user have the CAP_NET_ADMIN capability to run.
It's possible that the addition of this requirement is a non-starter.
Though I'm not 100% sure. Do you have any thoughts before I pursue
this further?
[1] http://bazaar.launchpad.net/~kees/+junk/cn_proc/files/3

On Mon, Jun 4, 2018, at 7:04 PM, Greg Clayton wrote:
> I will be too busy this week to get to this, so please do have a
> stab at it.> 
> Basically the flow that debug server does is:
> 1 - get a list of all processes whose basename matches and remember
> those pids so we don't try to attach to them since we are waiting for
> a new process to show up> 2 - poll the OS for the process list and wait for a 
> new pid to show up
> with the basename and attach to the first one that matches whose pid
> isn't i the list from step #1> 
> On MacOSX we don't have a way to be notified of new processes are
> spawned, not sure on other unix variants. If it is possible, we would
> want change to:> 1 - sign up to be notified about new processes
> 2 - as each process gets launched, check for a match and attach as
> quickly as possible> 
> Hope this helps and I look forward to seeing your patch!
> 
> Greg
> 
>> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett  wrote:
>> 
>> Greg,
>> 
>> Is there anything I can do to help you implement or test this
>> feature? Obviously I'm willing to roll-up my sleeves and work on this
>> myself too if you've become more busy than you expected. That happens
>> to us all and I completely understand.>> 
>> Not being able to debug in this manner is blocking me from adding
>> Linux support to a Swift program. As you might imagine, I'm a little
>> antsy to get past this so I can start writing some code.>> 
>> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
>>> 
>>> 
 On May 31, 2018, at 12:40 PM, Ryan Lovelett 
 wrote: 
 Well at least there is a little good news. I understood way more of
 those logs than I thought I did. 
> So two issues here:
> 1 - we need a better error message when vAttachWait returns
> unsupported> 2 - fix lldb-server to support vAttachWait
 
 A few questions.
 
 What is the protocol here? Can/should I report the issues at
 https://bugs.llvm.org/ ? Or is that something that a project member
 needs to do? Assuming that I can, would this be two seperate issues
 or one "large" issue? 
 Barring that this is not something someone else might implement
 better/faster than me. Considering I have zero LLDB development
 experience is this something that I could tackle?>>> 
>>> I didn't realize this functionality was missing in lldb-server. I
>>> can take a stab at implementing it and see what I can do. Stay
>>> tuned.>>> 
 
 On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
> lldb-server claims it doesn't support it:
> 
> lldb <  48> send packet:
> $vAttachWait;6c616e677365727665722d7377696674#d6> lldb <  
>  4> read packet: $#00
> 
> 
> Returning the empty packet ("$#00") means it is not supported, but
> we really should give a better error message than this.> 
> It isn't that hard to implement. It would be easy to copy the code
> that is in debugserver in DNB.cpp in the DNBProcessAttachWait
> function. Most of it is probably posix style stuff.> 
> So two issues here:
> 1 - we need a better error message when vAttachWait returns
> unsupported> 2 - fix lldb-server to support vAttachWait
> 
> Greg
> 
> 
>> On May 31, 2018, at 11:04 AM, Ryan Lovelett 
>> wrote:>> 
>>> It might be a lldb-server issue?
>> 
>> How would one go about determining this?
>> 
>> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
>> (lldb) process attach --name "" --waitfor
>> error: attach failed: lost connection
>> 
>> Attached the log output. Maybe it'll make more sense to you than
>> me.>> 
>> That escalated quickly. So I've read through that log. I found
>> something that says $qVAttachOrWaitSupported#38 with the
>> following response being $#00. Perhaps I'm reading too much but
>> is it that it's reporting that it is not supported?>> 
>> Does lldb-server need to be compiled in a certain way to add
>> support for attach wait?>> 
>> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
>>> Try enabling logging with:
>>> 
>>> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
>>> 
>>> And the try the attach. It might be a lldb-server issue?
>>> 
 On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev >>> d...@lists.llvm.org

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Greg Clayton via lldb-dev]

I will be too busy this week to get to this, so please do have a stab at it.

Basically the flow that debug server does is:
1 - get a list of all processes whose basename matches and remember those pids 
so we don't try to attach to them since we are waiting for a new process to 
show up
2 - poll the OS for the process list and wait for a new pid to show up with the 
basename and attach to the first one that matches whose pid isn't i the list 
from step #1

On MacOSX we don't have a way to be notified of new processes are spawned, not 
sure on other unix variants. If it is possible, we would want change to:
1 - sign up to be notified about new processes
2 - as each process gets launched, check for a match and attach as quickly as 
possible

Hope this helps and I look forward to seeing your patch!

Greg

> On Jun 4, 2018, at 5:56 AM, Ryan Lovelett  wrote:
> 
> Greg,
> 
> Is there anything I can do to help you implement or test this feature? 
> Obviously I'm willing to roll-up my sleeves and work on this myself too if 
> you've become more busy than you expected. That happens to us all and I 
> completely understand.
> 
> Not being able to debug in this manner is blocking me from adding Linux 
> support to a Swift program. As you might imagine, I'm a little antsy to get 
> past this so I can start writing some code. 
> 
> On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
>> 
>> 
>>> On May 31, 2018, at 12:40 PM, Ryan Lovelett >> > wrote:
>>> 
>>> Well at least there is a little good news. I understood way more of those 
>>> logs than I thought I did.
>>> 
 So two issues here:
 1 - we need a better error message when vAttachWait returns unsupported
 2 - fix lldb-server to support vAttachWait
>>> 
>>> A few questions.
>>> 
>>> What is the protocol here? Can/should I report the issues at 
>>> https://bugs.llvm.org/  ? Or is that something that 
>>> a project member needs to do? Assuming that I can, would this be two 
>>> seperate issues or one "large" issue?
>>> 
>>> Barring that this is not something someone else might implement 
>>> better/faster than me. Considering I have zero LLDB development experience 
>>> is this something that I could tackle?
>> 
>> I didn't realize this functionality was missing in lldb-server. I can take a 
>> stab at implementing it and see what I can do. Stay tuned.
>> 
>>> 
>>> On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
 lldb-server claims it doesn't support it:
 
 lldb <  48> send packet: 
 $vAttachWait;6c616e677365727665722d7377696674#d6
 lldb <   4> read packet: $#00
 
 
 Returning the empty packet ("$#00") means it is not supported, but we 
 really should give a better error message than this. 
 
 It isn't that hard to implement. It would be easy to copy the code that is 
 in debugserver in DNB.cpp in the DNBProcessAttachWait function. Most of it 
 is probably posix style stuff. 
 
 So two issues here:
 1 - we need a better error message when vAttachWait returns unsupported
 2 - fix lldb-server to support vAttachWait
 
 Greg
 
 
> On May 31, 2018, at 11:04 AM, Ryan Lovelett  > wrote:
> 
>> It might be a lldb-server issue?
> 
> How would one go about determining this?
> 
> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
> (lldb) process attach --name "" --waitfor
> error: attach failed: lost connection
> 
> Attached the log output. Maybe it'll make more sense to you than me.
> 
> That escalated quickly. So I've read through that log. I found something 
> that says $qVAttachOrWaitSupported#38 with the following response being 
> $#00. Perhaps I'm reading too much but is it that it's reporting that it 
> is not supported?
> 
> Does lldb-server need to be compiled in a certain way to add support for 
> attach wait?
> 
> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
>> Try enabling logging with:
>> 
>> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
>> 
>> And the try the attach. It might be a lldb-server issue?
>> 
>>> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> I am attempting to use: process attach --name "" --waitfor
>>> 
>>> The problem is that it immediately returns error: attach failed: lost 
>>> connection.
>>> 
>>> Is this something I can troubleshoot further? Or is this not supported 
>>> on Linux?
>>> 
>>> -- 
>>> Ryan Lovelett
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org 
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> 
> 

_

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

Greg,

Is there anything I can do to help you implement or test this feature?
Obviously I'm willing to roll-up my sleeves and work on this myself too
if you've become more busy than you expected. That happens to us all and
I completely understand.
Not being able to debug in this manner is blocking me from adding Linux
support to a Swift program. As you might imagine, I'm a little antsy to
get past this so I can start writing some code.
On Thu, May 31, 2018, at 5:08 PM, Greg Clayton wrote:
> 
> 
>> On May 31, 2018, at 12:40 PM, Ryan Lovelett  wrote:>> 
>> Well at least there is a little good news. I understood way more of
>> those logs than I thought I did.>> 
>>> So two issues here:
>>> 1 - we need a better error message when vAttachWait returns
>>> unsupported>>> 2 - fix lldb-server to support vAttachWait
>> 
>> A few questions.
>> 
>> What is the protocol here? Can/should I report the issues at
>> https://bugs.llvm.org/ ? Or is that something that a project member
>> needs to do? Assuming that I can, would this be two seperate issues
>> or one "large" issue?>> 
>> Barring that this is not something someone else might implement
>> better/faster than me. Considering I have zero LLDB development
>> experience is this something that I could tackle?> 
> I didn't realize this functionality was missing in lldb-server. I can
> take a stab at implementing it and see what I can do. Stay tuned.> 
>> 
>> On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
>>> lldb-server claims it doesn't support it:
>>> 
>>> lldb <  48> send packet:
>>> $vAttachWait;6c616e677365727665722d7377696674#d6>>> lldb <   4> 
>>> read packet: $#00
>>> 
>>> 
>>> Returning the empty packet ("$#00") means it is not supported, but
>>> we really should give a better error message than this.>>> 
>>> It isn't that hard to implement. It would be easy to copy the code
>>> that is in debugserver in DNB.cpp in the DNBProcessAttachWait
>>> function. Most of it is probably posix style stuff.>>> 
>>> So two issues here:
>>> 1 - we need a better error message when vAttachWait returns
>>> unsupported>>> 2 - fix lldb-server to support vAttachWait
>>> 
>>> Greg
>>> 
>>> 
 On May 31, 2018, at 11:04 AM, Ryan Lovelett 
 wrote: 
> It might be a lldb-server issue?
 
 How would one go about determining this?
 
 (lldb) log enable -f /tmp/packates.txt gdb-remote packets
 (lldb) process attach --name "" --waitfor
 error: attach failed: lost connection
 
 Attached the log output. Maybe it'll make more sense to you
 than me. 
 That escalated quickly. So I've read through that log. I found
 something that says $qVAttachOrWaitSupported#38 with the following
 response being $#00. Perhaps I'm reading too much but is it that
 it's reporting that it is not supported? 
 Does lldb-server need to be compiled in a certain way to add
 support for attach wait? 
 On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
> Try enabling logging with:
> 
> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
> 
> And the try the attach. It might be a lldb-server issue?
> 
>> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev > d...@lists.llvm.org> wrote:>> 
>> I am attempting to use: process attach --name "" --waitfor>> 
>> The problem is that it immediately returns error: attach failed:
>> lost connection.>> 
>> Is this something I can troubleshoot further? Or is this not
>> supported on Linux?>> 
>> -- 
>> Ryan Lovelett
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
 

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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Greg Clayton via lldb-dev]

> On May 31, 2018, at 12:40 PM, Ryan Lovelett  wrote:
> 
> Well at least there is a little good news. I understood way more of those 
> logs than I thought I did.
> 
>> So two issues here:
>> 1 - we need a better error message when vAttachWait returns unsupported
>> 2 - fix lldb-server to support vAttachWait
> 
> A few questions.
> 
> What is the protocol here? Can/should I report the issues at 
> https://bugs.llvm.org/  ? Or is that something that a 
> project member needs to do? Assuming that I can, would this be two seperate 
> issues or one "large" issue?
> 
> Barring that this is not something someone else might implement better/faster 
> than me. Considering I have zero LLDB development experience is this 
> something that I could tackle?

I didn't realize this functionality was missing in lldb-server. I can take a 
stab at implementing it and see what I can do. Stay tuned.

> 
> On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
>> lldb-server claims it doesn't support it:
>> 
>> lldb <  48> send packet: 
>> $vAttachWait;6c616e677365727665722d7377696674#d6
>> lldb <   4> read packet: $#00
>> 
>> 
>> Returning the empty packet ("$#00") means it is not supported, but we really 
>> should give a better error message than this. 
>> 
>> It isn't that hard to implement. It would be easy to copy the code that is 
>> in debugserver in DNB.cpp in the DNBProcessAttachWait function. Most of it 
>> is probably posix style stuff. 
>> 
>> So two issues here:
>> 1 - we need a better error message when vAttachWait returns unsupported
>> 2 - fix lldb-server to support vAttachWait
>> 
>> Greg
>> 
>> 
>>> On May 31, 2018, at 11:04 AM, Ryan Lovelett >> > wrote:
>>> 
 It might be a lldb-server issue?
>>> 
>>> How would one go about determining this?
>>> 
>>> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
>>> (lldb) process attach --name "" --waitfor
>>> error: attach failed: lost connection
>>> 
>>> Attached the log output. Maybe it'll make more sense to you than me.
>>> 
>>> That escalated quickly. So I've read through that log. I found something 
>>> that says $qVAttachOrWaitSupported#38 with the following response being 
>>> $#00. Perhaps I'm reading too much but is it that it's reporting that it is 
>>> not supported?
>>> 
>>> Does lldb-server need to be compiled in a certain way to add support for 
>>> attach wait?
>>> 
>>> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
 Try enabling logging with:
 
 (lldb) log enable -f /tmp/packets.txt gdb-remote packets
 
 And the try the attach. It might be a lldb-server issue?
 
> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> I am attempting to use: process attach --name "" --waitfor
> 
> The problem is that it immediately returns error: attach failed: lost 
> connection.
> 
> Is this something I can troubleshoot further? Or is this not supported on 
> Linux?
> 
> -- 
> Ryan Lovelett
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 

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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Davide Italiano via lldb-dev]

On Thu, May 31, 2018 at 12:40 PM, Ryan Lovelett via lldb-dev
 wrote:
> Well at least there is a little good news. I understood way more of those
> logs than I thought I did.
>
> So two issues here:
> 1 - we need a better error message when vAttachWait returns unsupported
> 2 - fix lldb-server to support vAttachWait
>
>
> A few questions.
>
> What is the protocol here? Can/should I report the issues at
> https://bugs.llvm.org/ ? Or is that something that a project member needs to
> do? Assuming that I can, would this be two seperate issues or one "large"
> issue?
>

You can open a bug on bugzilla (you can ask an account via e-mail).

> Barring that this is not something someone else might implement
> better/faster than me. Considering I have zero LLDB development experience
> is this something that I could tackle?
>

You can try and see how far you get (and ask questions, either here or
on IRC oftc.net/#lldb)

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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

Well at least there is a little good news. I understood way more of
those logs than I thought I did.
> So two issues here:
> 1 - we need a better error message when vAttachWait returns
> unsupported> 2 - fix lldb-server to support vAttachWait

A few questions.

What is the protocol here? Can/should I report the issues at
https://bugs.llvm.org/ ? Or is that something that a project member
needs to do? Assuming that I can, would this be two seperate issues or
one "large" issue?
Barring that this is not something someone else might implement
better/faster than me. Considering I have zero LLDB development
experience is this something that I could tackle?
On Thu, May 31, 2018, at 3:02 PM, Greg Clayton wrote:
> lldb-server claims it doesn't support it:
> 
> lldb <  48> send packet:
> $vAttachWait;6c616e677365727665722d7377696674#d6> lldb <   4> 
> read packet: $#00
> 
> 
> Returning the empty packet ("$#00") means it is not supported, but we
> really should give a better error message than this.> 
> It isn't that hard to implement. It would be easy to copy the code
> that is in debugserver in DNB.cpp in the DNBProcessAttachWait
> function. Most of it is probably posix style stuff.> 
> So two issues here:
> 1 - we need a better error message when vAttachWait returns
> unsupported> 2 - fix lldb-server to support vAttachWait
> 
> Greg
> 
> 
>> On May 31, 2018, at 11:04 AM, Ryan Lovelett  wrote:>> 
>>> It might be a lldb-server issue?
>> 
>> How would one go about determining this?
>> 
>> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
>> (lldb) process attach --name "" --waitfor
>> error: attach failed: lost connection
>> 
>> Attached the log output. Maybe it'll make more sense to you than me.>> 
>> That escalated quickly. So I've read through that log. I found
>> something that says $qVAttachOrWaitSupported#38 with the following
>> response being $#00. Perhaps I'm reading too much but is it that it's
>> reporting that it is not supported?>> 
>> Does lldb-server need to be compiled in a certain way to add support
>> for attach wait?>> 
>> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
>>> Try enabling logging with:
>>> 
>>> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
>>> 
>>> And the try the attach. It might be a lldb-server issue?
>>> 
 On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev >>> d...@lists.llvm.org> wrote: 
 I am attempting to use: process attach --name "" --waitfor
 
 The problem is that it immediately returns error: attach failed:
 lost connection. 
 Is this something I can troubleshoot further? Or is this not
 supported on Linux? 
 -- 
 Ryan Lovelett
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 

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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Greg Clayton via lldb-dev]

lldb-server claims it doesn't support it:

lldb <  48> send packet: 
$vAttachWait;6c616e677365727665722d7377696674#d6
lldb <   4> read packet: $#00


Returning the empty packet ("$#00") means it is not supported, but we really 
should give a better error message than this. 

It isn't that hard to implement. It would be easy to copy the code that is in 
debugserver in DNB.cpp in the DNBProcessAttachWait function. Most of it is 
probably posix style stuff. 

So two issues here:
1 - we need a better error message when vAttachWait returns unsupported
2 - fix lldb-server to support vAttachWait

Greg


> On May 31, 2018, at 11:04 AM, Ryan Lovelett  wrote:
> 
>> It might be a lldb-server issue?
> 
> How would one go about determining this?
> 
> (lldb) log enable -f /tmp/packates.txt gdb-remote packets
> (lldb) process attach --name "" --waitfor
> error: attach failed: lost connection
> 
> Attached the log output. Maybe it'll make more sense to you than me.
> 
> That escalated quickly. So I've read through that log. I found something that 
> says $qVAttachOrWaitSupported#38 with the following response being $#00. 
> Perhaps I'm reading too much but is it that it's reporting that it is not 
> supported?
> 
> Does lldb-server need to be compiled in a certain way to add support for 
> attach wait?
> 
> On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
>> Try enabling logging with:
>> 
>> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
>> 
>> And the try the attach. It might be a lldb-server issue?
>> 
>>> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev 
>>>  wrote:
>>> 
>>> I am attempting to use: process attach --name "" --waitfor
>>> 
>>> The problem is that it immediately returns error: attach failed: lost 
>>> connection.
>>> 
>>> Is this something I can troubleshoot further? Or is this not supported on 
>>> Linux?
>>> 
>>> -- 
>>> Ryan Lovelett
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> 

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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

> It might be a lldb-server issue?

How would one go about determining this?

(lldb) log enable -f /tmp/packates.txt gdb-remote packets
(lldb) process attach --name "" --waitfor
error: attach failed: lost connection

Attached the log output. Maybe it'll make more sense to you than me.

That escalated quickly. So I've read through that log. I found something that 
says $qVAttachOrWaitSupported#38 with the following response being $#00. 
Perhaps I'm reading too much but is it that it's reporting that it is not 
supported?

Does lldb-server need to be compiled in a certain way to add support for attach 
wait?

On Thu, May 31, 2018, at 1:49 PM, Greg Clayton wrote:
> Try enabling logging with:
> 
> (lldb) log enable -f /tmp/packets.txt gdb-remote packets
> 
> And the try the attach. It might be a lldb-server issue?
> 
> > On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev 
> >  wrote:
> > 
> > I am attempting to use: process attach --name "" --waitfor
> > 
> > The problem is that it immediately returns error: attach failed: lost 
> > connection.
> > 
> > Is this something I can troubleshoot further? Or is this not supported on 
> > Linux?
> > 
> > -- 
> >  Ryan Lovelett
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
lldb <   1> send packet: +
lldb history[1] tid=0x29c5 <   1> send packet: +
lldb <  19> send packet: $QStartNoAckMode#b0
lldb <   1> read packet: +
lldb <   6> read packet: $OK#9a
lldb <   1> send packet: +
lldb <  41> send packet: $qSupported:xmlRegisters=i386,arm,mips#12
lldb < 124> read packet: 
$PacketSize=2;QStartNoAckMode+;QThreadSuffixSupported+;QListThreadsInStopReply+;qEcho+;QPassSignals+;qXfer:auxv:read+#be
lldb <  26> send packet: $QThreadSuffixSupported#e4
lldb <   6> read packet: $OK#9a
lldb <  27> send packet: $QListThreadsInStopReply#21
lldb <   6> read packet: $OK#9a
lldb <  13> send packet: $qHostInfo#9b
lldb < 337> read packet: 
$triple:7838365f36342d2d6c696e75782d676e75;ptrsize:8;distribution_id:7562756e7475;watchpoint_exceptions_received:after;endian:little;os_version:4.15.0;os_build:342e31352e302d32322d67656e65726963;os_kernel:2332342d5562756e747520534d5020576564204d61792031362031323a31353a3137205554432032303138;hostname:7562756e74752d73776966742d646576;#46
lldb <  10> send packet: $vCont?#49
lldb <  17> read packet: $vCont;c;C;s;S#62
lldb <  27> send packet: $qVAttachOrWaitSupported#38
lldb <   4> read packet: $#00
lldb <  23> send packet: $QEnableErrorStrings#8c
lldb <   6> read packet: $OK#9a
lldb <  23> send packet: $QSetDetachOnError:1#f8
lldb <   6> read packet: $OK#9a
lldb <  48> send packet: 
$vAttachWait;6c616e677365727665722d7377696674#d6
lldb <   4> read packet: $#00
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

[Greg Clayton via lldb-dev]

Try enabling logging with:

(lldb) log enable -f /tmp/packets.txt gdb-remote packets

And the try the attach. It might be a lldb-server issue?

> On May 31, 2018, at 9:02 AM, Ryan Lovelett via lldb-dev 
>  wrote:
> 
> I am attempting to use: process attach --name "" --waitfor
> 
> The problem is that it immediately returns error: attach failed: lost 
> connection.
> 
> Is this something I can troubleshoot further? Or is this not supported on 
> Linux?
> 
> -- 
>  Ryan Lovelett
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] LLDB Process Attach Failed When Waiting

[Ryan Lovelett via lldb-dev]

I am attempting to use: process attach --name "" --waitfor

The problem is that it immediately returns error: attach failed: lost 
connection.

Is this something I can troubleshoot further? Or is this not supported on Linux?

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