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