[lldb-dev] LLDB Process Attach Failed When Waiting

[Greg Clayton via lldb-dev]

> On Jun 6, 2018, at 2:20 PM, Ryan Lovelett <ryan at lovelett.me> 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 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 another function that should be used for Linux?

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 peg the CPU at 100% while waiting.

> 
> 2. DNBProcessAttachWait seems to have a timeout capability [2]. As far as I can tell, the argument timeout_abstime is hard-coded as NULL. Thus rendering that timer/timeout dead code.  Should replicate that in the Linux code as well?

No need for now.

> 
> 3. Are there, or are there expected to be, tests for this stuff?

Yes! There are many lldb-server tests already. Pavel should be able to direct you to how and where to make these tests.

> 
> [1] https://github.com/llvm-mirror/lldb/blob/b64ab3f60c8faa43841af88b10dbcbfd073a82ea/tools/debugserver/source/DNB.cpp#L743
> [2] https://github.com/llvm-mirror/lldb/blob/b64ab3f60c8faa43841af88b10dbcbfd073a82ea/tools/debugserver/source/DNB.cpp#L720-L729
> 
> On Wed, Jun 6, 2018, at 10:38 AM, Pavel Labath wrote:
>> 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 this point)
>> - let the client send the packet
>> - step through the server as it processes it
>> 
>> That's if you want an interactive debug session. If you just want to
>> see the logs, it should be sufficient to set LLDB_DEBUGSERVER_LOG_FILE
>> and LLDB_SERVER_LOG_CHANNELS environment variables before starting
>> lldb.
>> 
>> On Wed, 6 Jun 2018 at 13:59, Ryan Lovelett <ryan at lovelett.me> wrote:
>>> 
>>> 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
>> 
>> This won't work. You are starting up a "gdb-server" instance of
>> lldb-server and then connecting to it as if it was a platform
>> instance. For "local" debugging you don't need that. You only need to
>> mess with the platform when doing "true" remote debugging  That's
>> probably why the latter attempt to attach fails with a weird error.