Revert r273524, it may have been the cause of a linux testbot failure

for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll
need to look at this more closely before re-committing.  (passed OK on
macOS ;)

llvm-svn: 273531

1 files changed, 2 insertions, 2 deletions

diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index c8ccaaed2e0..13db5cef0ad 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -2902,9 +2902,9 @@ ProcessGDBRemote::DoDestroy ()
                 if (packet_cmd == 'W' || packet_cmd == 'X')
                 {
 #if defined(__APPLE__)
-                    // For Native processes on macOS, we launch through the Host Platform, then hand the process off
+                    // For Native processes on Mac OS X, we launch through the Host Platform, then hand the process off
                     // to debugserver, which becomes the parent process through "PT_ATTACH".  Then when we go to kill
-                    // the process on macOS we call ptrace(PT_KILL) to kill it, then we call waitpid which returns
+                    // the process on Mac OS X we call ptrace(PT_KILL) to kill it, then we call waitpid which returns
                     // with no error and the correct status.  But amusingly enough that doesn't seem to actually reap
                     // the process, but instead it is left around as a Zombie.  Probably the kernel is in the process of
                     // switching ownership back to lldb which was the original parent, and gets confused in the handoff.