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
