> On Jun 6, 2018, at 2:20 PM, Ryan Lovelett <r...@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 <r...@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. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
