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