[lldb-dev] LLDB Process Attach Failed When Waiting

Wed Jun 6 00:59:53 PDT 2018

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
<lldb-dev at lists.llvm.org> 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 <lldb-dev at lists.llvm.org> 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 <ryan at lovelett.me> 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 <ryan at lovelett.me> 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 <ryan at lovelett.me> 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 "<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 <lldb-dev at lists.llvm.org> wrote:
> > >>>>>>>>>
> > >>>>>>>>> I am attempting to use: process attach --name "<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 at lists.llvm.org
> > >>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >>>>>>> <packates.txt>
> > >
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev