Ensure lldb-server waits for child debug servers to start up when passing them a port number to listen on.

[hhellyer]

Summary

When lldb-server is started with the -P <port> or -m/-M <min/max port> options to specify which ports are available for remote connections the child debug server is told what port it should listen on. In those cases lldb-server needs to wait for the child to report it’s port number as otherwise it can tell the lldb client that the child is up and listening before it is actually listening on that port. lldb-server already waits in the cases where a port wasn’t specified by waiting until the child reports the port it is using. It was skipping this synchronisation step when passed a port numbers as it knew what the port would be however it does need to ensure the child process has had time to open that port and waiting until the child reports the port number makes sure this has happened.

This patch just removes the one case where a child was spawned and lldb-server did not wait for it to report it’s port number before telling the client lldb process the child is ready to connect to.

This issue was discussed on lldb-dev in a thread here:
http://lists.llvm.org/pipermail/lldb-dev/2017-February/012002.html

[clayborg]

Looks good.

source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp

#endif
     // TCP port or domain socket name which it listens on.
     // The second purpose of the pipe to serve as a synchronization point -
     // once data is written to the pipe, debug server is up and running.
     Pipe socket_pipe;
 
     // port is null when debug server should listen on domain socket -
     // we're not interested in port value but rather waiting for debug server
     // to become available.
-    if (pass_comm_fd == -1 &&
-        ((port != nullptr && *port == 0) || port == nullptr)) {
+    if (pass_comm_fd == -1) {
       if (url) {
 // Create a temporary file to get the stdout/stderr and redirect the
 // output of the command into this file. We will later read this file
 // if all goes well and fill the data into "command_output_ptr"
 #if defined(__APPLE__)
         // Binding to port zero, we need to figure out what port it ends up
         // using using a named pipe...
         error = socket_pipe.CreateWithUniqueName("debugserver-named-pipe",
if (error.Success() &&
         char port_cstr[PATH_MAX] = {0};
         port_cstr[0] = '\0';
         size_t num_bytes = sizeof(port_cstr);
         // Read port from pipe with 10 second timeout.
         error = socket_pipe.ReadWithTimeout(
             port_cstr, num_bytes, std::chrono::seconds{10}, num_bytes);
         if (error.Success() && (port != nullptr)) {
           assert(num_bytes > 0 && port_cstr[num_bytes - 1] == '\0');
-          *port = StringConvert::ToUInt32(port_cstr, 0);
+          uint16_t child_port = StringConvert::ToUInt32(port_cstr, 0);
+          if (*port == 0 || *port == child_port) {
+            *port = child_port;
             if (log)
               log->Printf("GDBRemoteCommunication::%s() "
                           "debugserver listens %u port",
                           __FUNCTION__, *port);
           } else {
             if (log)
               log->Printf("GDBRemoteCommunication::%s() "
+                          "debugserver listening on port "
+                          "%d but requested port was %d",
+                          __FUNCTION__, (uint32_t)child_port,
+                          (uint32_t)(*port));
+          }
+        } else {
+          if (log)
+            log->Printf("GDBRemoteCommunication::%s() "
                         "failed to read a port value from pipe %s: %s",
                         __FUNCTION__, named_pipe_path.c_str(),
                         error.AsCString());
         }
         socket_pipe.Close();
       }
 
       if (named_pipe_path.size() > 0) {