Unify process launching code on linux

Summary:
We've had two copies of code for launching processes:
- one in NativeProcessLinux, used for launching debugged processes
- one in ProcessLauncherAndroid, used on android for launching all other kinds of processes

These have over time acquired support for various launch options, but neither supported all of
them. I now replace them with a single implementation ProcessLauncherLinux, which supports all
the options the individual versions supported and set it to be used to launch all processes on
linux.

This also works around the ETXTBSY issue on android when the process is started from the platform
instance, as that used to go through the version which did not contain the workaround.

Reviewers: tberghammer

Subscribers: tberghammer, danalbert, srhines, lldb-commits

Differential Revision: https://reviews.llvm.org/D22457

llvm-svn: 276288

1 files changed, 10 insertions, 13 deletions

diff --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
index fc6b31e..ede6976 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -203,6 +203,15 @@ GDBRemoteCommunicationServerLLGS::LaunchProcess ()
     if (!m_process_launch_info.GetArguments ().GetArgumentCount ())
         return Error ("%s: no process command line specified to launch", __FUNCTION__);
 
+    const bool should_forward_stdio = m_process_launch_info.GetFileActionForFD(STDIN_FILENO) == nullptr ||
+                                      m_process_launch_info.GetFileActionForFD(STDOUT_FILENO) == nullptr ||
+                                      m_process_launch_info.GetFileActionForFD(STDERR_FILENO) == nullptr;
+    m_process_launch_info.SetLaunchInSeparateProcessGroup(true);
+    m_process_launch_info.GetFlags().Set(eLaunchFlagDebug);
+
+    const bool default_to_use_pty = true;
+    m_process_launch_info.FinalizeFileActions(nullptr, default_to_use_pty);
+
     Error error;
     {
         std::lock_guard<std::recursive_mutex> guard(m_debugged_process_mutex);
@@ -226,11 +235,7 @@ GDBRemoteCommunicationServerLLGS::LaunchProcess ()
     // file actions non-null
     // process launch -i/e/o will also make these file actions non-null
     // nullptr means that the traffic is expected to flow over gdb-remote protocol
-    if (
-        m_process_launch_info.GetFileActionForFD(STDIN_FILENO) == nullptr  ||
-        m_process_launch_info.GetFileActionForFD(STDOUT_FILENO) == nullptr  ||
-        m_process_launch_info.GetFileActionForFD(STDERR_FILENO) == nullptr
-        )
+    if (should_forward_stdio)
     {
         // nullptr means it's not redirected to file or pty (in case of LLGS local)
         // at least one of stdio will be transferred pty<->gdb-remote
@@ -998,14 +1003,6 @@ GDBRemoteCommunicationServerLLGS::StartSTDIOForwarding()
     if (! m_stdio_communication.IsConnected())
         return;
 
-    // llgs local-process debugging may specify PTY paths, which will make these
-    // file actions non-null
-    // process launch -e/o will also make these file actions non-null
-    // nullptr means that the traffic is expected to flow over gdb-remote protocol
-    if ( m_process_launch_info.GetFileActionForFD(STDOUT_FILENO) &&
-         m_process_launch_info.GetFileActionForFD(STDERR_FILENO))
-        return;
-
     Error error;
     lldbassert(! m_stdio_handle_up);
     m_stdio_handle_up = m_mainloop.RegisterReadObject(