Re: [lldb-dev] LLDB Process Attach Failed When Waiting

> sleep_for is definitely better than usleep because of portability (and > we use it elsewhere already). Okay that is what I went with. > Could you attach the patch to phabricator instead > ? It's easier to make > comments and iterate there. When you uplo

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

sleep_for is definitely better than usleep because of portability (and we use it elsewhere already). Could you attach the patch to phabricator instead ? It's easier to make comments and iterate there. When you upload the patch be sure to include full contex

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

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

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

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

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 th

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 lik

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

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 S

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

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 GetProcessNameF

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

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.

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

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 connecti

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

On Tue, 5 Jun 2018 at 01:18, Ryan Lovelett via lldb-dev wrote: > > So I've found a capability on Linux to be notified about new processes. I > have an example of listening for these new processes running on my machine > now [1] and I can see when my desired user process spawns. Though > documen

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

So I've found a capability on Linux to be notified about new processes. I have an example of listening for these new processes running on my machine now [1] and I can see when my desired user process spawns. Though documentation on the API is scarce. It also requires that the executable or user hav

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

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 t

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

> On May 31, 2018, at 12:40 PM, Ryan Lovelett 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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

On Thu, May 31, 2018 at 12:40 PM, Ryan Lovelett via lldb-dev 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 su

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

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

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

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.

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

> 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 "" --waitfor error: attach failed: lost connection Attached the log output. Maybe it'll make more sense to you than me. That escalat

Re: [lldb-dev] LLDB Process Attach Failed When Waiting

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 > wrote: > > I am attempting to use: process attach --name "" --waitfor > > The problem is th

[lldb-dev] LLDB Process Attach Failed When Waiting

I am attempting to use: process attach --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-