Re: [lldb-dev] LLDB Process Attach Failed When Waiting
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
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
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
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] MacOS minidump debugging
Yes. On Tue, Jun 5, 2018 at 7:33 PM, Zachary Turner wrote: > I assume you're referring to a windows minidump as opposed to a Mac core > file? > > On Tue, Jun 5, 2018 at 4:19 PM Rustam Hashimov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi, >> lldb newbie here. >> Has anyone debugged minidump with lldb in MacOS. Any documentation or >> pointers would be appreciated! >> >> Thanks, >> Rustam >> ___ >> 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] MacOS minidump debugging
We don't have support for reading mac minidumps presently. That said, it probably wouldn't be too hard to add one, as we already have windows and linux minidumps working (to some degree, at least). It would probably require adding parsing support for some OS-specific structures (I recall some things are stored differently between linux & windows, so I expect there to be some for osx as well). On Wed, 6 Jun 2018 at 16:11, Rustam Hashimov via lldb-dev wrote: > > Yes. > > On Tue, Jun 5, 2018 at 7:33 PM, Zachary Turner wrote: >> >> I assume you're referring to a windows minidump as opposed to a Mac core >> file? >> >> On Tue, Jun 5, 2018 at 4:19 PM Rustam Hashimov via lldb-dev >> wrote: >>> >>> Hi, >>> lldb newbie here. >>> Has anyone debugged minidump with lldb in MacOS. Any documentation or >>> pointers would be appreciated! >>> >>> Thanks, >>> Rustam >>> ___ >>> 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 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
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
> 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
> 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
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");
+
+
