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@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 <r...@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 <r...@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 <r...@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@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@lists.llvm.org >>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>>>>> <packates.txt> > > _______________________________________________ > 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
