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

lldb/.gitignore

@@ -21,7 +21,7 @@
 # vim swap files
 .*.swp
 .sw?
-# macOS specific files.
+# OS X specific files.
 .DS_store
 DerivedData/
 

lldb/docs/lldb-gdb-remote.txt

@@ -896,7 +896,7 @@ tuples to return are:
 If the address requested is not in a mapped region (e.g. we've jumped through
 a NULL pointer and are at 0x0) currently lldb expects to get back the size 
 of the unmapped region -- that is, the distance to the next valid region.
-For instance, with a macOS process which has nothing mapped in the first
+For instance, with a Mac OS X process which has nothing mapped in the first
 4GB of its address space, if we're asking about address 0x2,
 
   qMemoryRegionInfo:2
@@ -1399,7 +1399,7 @@ for this region.
 //
 // Because this is a JSON string, the thread number is provided in base10.
 // Additional key-value pairs may be provided by lldb to the gdb remote
-// stub.  For instance, on some versions of macOS, lldb can read offset
+// stub.  For instance, on some versions of Mac OS X, lldb can read offset
 // information out of the system libraries.  Using those offsets, debugserver
 // is able to find the Thread Specific Address (TSD) for a thread and include
 // that in the return information.  So lldb will send these additional fields
@@ -1562,7 +1562,7 @@ for this region.
 // quite a bit to provide all the information that the DynamicLoaderMacOSX
 // would need to work correctly on this platform.
 //
-// On macOS / iOS, when libraries are added or removed, a stub
+// On Mac OS X / iOS, when libraries are added or removed, a stub
 // function is called which lldb puts a breakpoint on.  The arguments
 // to the stub function include the number of libraries being added
 // or removed and the address where the list of libraries can be

lldb/docs/testsuite/a-detailed-walkthrough.txt

@@ -123,7 +123,7 @@ And the test/plugins/darwin.py provides the implementation for all three build
 methods using the makefile mechanism.  We envision that linux plugin can use a
 similar approach to accomplish the task of building the binaries.
 
-macOS provides an additional way to manipulate archived DWARF debug symbol
+Mac OS X provides an additional way to manipulate archived DWARF debug symbol
 files and produces dSYM files.  The buildDsym() instance method is used by the
 test method to build the binary with dsym info.  For an example of this,
 see test/array_types/TestArrayTypes.py:
@@ -136,7 +136,7 @@ see test/array_types/TestArrayTypes.py:
 
 This method is decorated with a skipUnless decorator so that it will only gets
 included into the test suite if the platform it is running on is 'darwin', aka
-macOS.
+Mac OS X.
 
 Type 'man dsymutil' for more details. 
 

lldb/include/lldb/Symbol/CompactUnwindInfo.h

@@ -29,7 +29,7 @@ namespace lldb_private {
 // i386/x86_64 for instance.  When a function is too complex to be represented in
 // the compact unwind format, it calls out to eh_frame unwind instructions.
 
-// On macOS / iOS, a function will have either a compact unwind representation 
+// On Mac OS X / iOS, a function will have either a compact unwind representation 
 // or an eh_frame representation.  If lldb is going to benefit  from the compiler's 
 // description about saved register locations, it must be able to read both 
 // sources of information.

lldb/include/lldb/Target/Thread.h

@@ -336,7 +336,7 @@ public:
     //------------------------------------------------------------------
     /// Retrieve a dictionary of information about this thread 
     ///
-    /// On macOS systems there may be voucher information.
+    /// On Mac OS X systems there may be voucher information.
     /// The top level dictionary returned will have an "activity" key and the
     /// value of the activity is a dictionary.  Keys in that dictionary will 
     /// be "name" and "id", among others.

lldb/source/Host/common/Editline.cpp

@@ -24,7 +24,7 @@
 using namespace lldb_private;
 using namespace lldb_private::line_editor;
 
-// Workaround for what looks like an macOS-specific issue, but other platforms
+// Workaround for what looks like an OS X-specific issue, but other platforms
 // may benefit from something similar if issues arise.  The libedit library
 // doesn't explicitly initialize the curses termcap library, which it gets away
 // with until TERM is set to VT100 where it stumbles over an implementation

lldb/source/Host/macosx/HostInfoMacOSX.mm

@@ -160,7 +160,7 @@ HostInfoMacOSX::ComputeSupportExeDirectory(FileSpec &file_spec)
     else
     {
         // Find the bin path relative to the lib path where the cmake-based
-        // macOS .dylib lives.  This is not going to work if the bin and lib
+        // OS X .dylib lives.  This is not going to work if the bin and lib
         // dir are not both in the same dir.
         //
         // It is not going to work to do it by the executable path either,

lldb/source/Plugins/ABI/MacOSX-arm/ABIMacOSX_arm.cpp

@@ -937,7 +937,7 @@ void
 ABIMacOSX_arm::Initialize()
 {
     PluginManager::RegisterPlugin (GetPluginNameStatic(),
-                                   "Darwin ABI for arm targets",
+                                   "Mac OS X ABI for arm targets",
                                    CreateInstance);    
 }
 

lldb/source/Plugins/ABI/MacOSX-arm64/ABIMacOSX_arm64.cpp

@@ -38,7 +38,7 @@
 using namespace lldb;
 using namespace lldb_private;
 
-static const char *pluginDesc = "Darwin ABI for arm64 targets";
+static const char *pluginDesc = "Mac OS X ABI for arm64 targets";
 
 static RegisterInfo g_register_infos[] = 
 {

lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp

@@ -609,7 +609,7 @@ void
 ABIMacOSX_i386::Initialize()
 {
     PluginManager::RegisterPlugin (GetPluginNameStatic(),
-                                   "macOS ABI for i386 targets",
+                                   "Mac OS X ABI for i386 targets",
                                    CreateInstance);    
 }
 

lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.cpp

@@ -493,7 +493,7 @@ DynamicLoaderMacOSXDYLD::UpdateImageLoadAddress (Module *module, DYLDImageInfo&
                         else
                         {
                             Host::SystemLog (Host::eSystemLogWarning, 
-                                             "warning: unable to find and load segment named '%s' at 0x%" PRIx64 " in '%s' in macOS dynamic loader plug-in.\n",
+                                             "warning: unable to find and load segment named '%s' at 0x%" PRIx64 " in '%s' in macosx dynamic loader plug-in.\n",
                                              info.segments[i].name.AsCString("<invalid>"),
                                              (uint64_t)new_section_load_addr,
                                              image_object_file->GetFileSpec().GetPath().c_str());
@@ -572,7 +572,7 @@ DynamicLoaderMacOSXDYLD::UnloadImageLoadAddress (Module *module, DYLDImageInfo&
                     else
                     {
                         Host::SystemLog (Host::eSystemLogWarning, 
-                                         "warning: unable to find and unload segment named '%s' in '%s' in macOS dynamic loader plug-in.\n",
+                                         "warning: unable to find and unload segment named '%s' in '%s' in macosx dynamic loader plug-in.\n",
                                          info.segments[i].name.AsCString("<invalid>"),
                                          image_object_file->GetFileSpec().GetPath().c_str());
                     }
@@ -1541,7 +1541,7 @@ DynamicLoaderMacOSXDYLD::UpdateImageInfosHeaderAndLoadCommands(DYLDImageInfo::co
 }
 
 //----------------------------------------------------------------------
-// On macOS libobjc (the Objective-C runtime) has several critical dispatch
+// On Mac OS X libobjc (the Objective-C runtime) has several critical dispatch
 // functions written in hand-written assembly, and also have hand-written unwind
 // information in the eh_frame section.  Normally we prefer analyzing the 
 // assembly instructions of a currently executing frame to unwind from that frame --
@@ -2007,7 +2007,7 @@ DynamicLoaderMacOSXDYLD::GetPluginNameStatic()
 const char *
 DynamicLoaderMacOSXDYLD::GetPluginDescriptionStatic()
 {
-    return "Dynamic loader plug-in that watches for shared library loads/unloads in macOS user processes.";
+    return "Dynamic loader plug-in that watches for shared library loads/unloads in MacOSX user processes.";
 }
 
 

lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

@@ -4810,7 +4810,7 @@ ObjectFileMachO::GetUUID (const llvm::MachO::mach_header &header,
             
             if (uuid_bytes)
             {
-                // OpenCL on macOS uses the same UUID for each of its object files.
+                // OpenCL on Mac OS X uses the same UUID for each of its object files.
                 // We pretend these object files have no UUID to prevent crashing.
                 
                 const uint8_t opencl_uuid[] = { 0x8c, 0x8e, 0xb3, 0x9b,
@@ -5054,8 +5054,8 @@ ObjectFileMachO::GetEntryPointAddress ()
     //
     // So we just keep reading the various register flavors till we find the GPR one, then read the PC out of there.
     // FIXME: We will need to have a "RegisterContext data provider" class at some point that can get all the registers
-    // out of data in this form & attach them to a given thread.  That should underlie the macOS User process plugin,
+    // out of data in this form & attach them to a given thread.  That should underlie the MacOS X User process plugin,
-    // and we'll also need it for the macOS Core File process plugin.  When we have that we can also use it here.
+    // and we'll also need it for the MacOS X Core File process plugin.  When we have that we can also use it here.
     //
     // For now we hard-code the offsets and flavors we need:
     //

lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp

@@ -508,7 +508,7 @@ PlatformLinux::GetStatus (Stream &strm)
 #ifndef LLDB_DISABLE_POSIX
     // Display local kernel information only when we are running in host mode.
     // Otherwise, we would end up printing non-Linux information (when running
-    // on macOS for example).
+    // on Mac OS for example).
     if (IsHost())
     {
         struct utsname un;

lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp

@@ -317,7 +317,7 @@ PlatformDarwinKernel::GetStatus (Stream &strm)
     if (m_ios_debug_session == eLazyBoolYes)
         strm.Printf ("iOS kernel debugging\n");
     else if (m_ios_debug_session == eLazyBoolNo)
-        strm.Printf ("macOS kernel debugging\n");
+        strm.Printf ("Mac OS X kernel debugging\n");
     else
             strm.Printf ("unknown kernel debugging\n");
     const uint32_t num_kext_dirs = m_search_directories.size();

lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h

@@ -141,11 +141,11 @@ protected:
     void
     GetWatchOSSDKDirectoriesToSearch (std::vector<lldb_private::FileSpec> &directories);
 
-    // Directories where we may find macOS SDKs with kext bundles in them
+    // Directories where we may find Mac OS X SDKs with kext bundles in them
     void
     GetMacSDKDirectoriesToSearch (std::vector<lldb_private::FileSpec> &directories);
 
-    // Directories where we may find macOS or iOS SDKs with kext bundles in them
+    // Directories where we may find Mac OS X or iOS SDKs with kext bundles in them
     void
     GetGenericSDKDirectoriesToSearch (std::vector<lldb_private::FileSpec> &directories);
 

lldb/source/Plugins/Platform/MacOSX/PlatformMacOSX.cpp

@@ -167,9 +167,9 @@ const char *
 PlatformMacOSX::GetDescriptionStatic (bool is_host)
 {
     if (is_host)
-        return "Local macOS user platform plug-in.";
+        return "Local Mac OS X user platform plug-in.";
     else
-        return "Remote macOS user platform plug-in.";
+        return "Remote Mac OS X user platform plug-in.";
 }
 
 //------------------------------------------------------------------

lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp

@@ -855,7 +855,7 @@ RegisterContextLLDB::GetFullUnwindPlanForFrame ()
         return arch_default_unwind_plan_sp;
     }
 
-    // If we're in _sigtramp(), unwinding past this frame requires special knowledge.  On macOS this knowledge
+    // If we're in _sigtramp(), unwinding past this frame requires special knowledge.  On Mac OS X this knowledge
     // is properly encoded in the eh_frame section, so prefer that if available.
     // On other platforms we may need to provide a platform-specific UnwindPlan which encodes the details of
     // how to unwind out of sigtramp.

lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp

@@ -224,7 +224,7 @@ UnwindLLDB::GetOneMoreFrame (ABI* abi)
     }
     if (abi && !abi->CallFrameAddressIsValid(cursor_sp->cfa))
     {
-        // On macOS, the _sigtramp asynchronous signal trampoline frame may not have
+        // On Mac OS X, the _sigtramp asynchronous signal trampoline frame may not have
         // its (constructed) CFA aligned correctly -- don't do the abi alignment check for
         // these.
         if (reg_ctx_sp->IsTrapHandlerFrame() == false)

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.

lldb/source/Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.cpp

@@ -141,7 +141,7 @@ SymbolVendorMacOSX::CreateInstance (const lldb::ModuleSP &module_sp, lldb_privat
         char path[PATH_MAX];
         path[0] = '\0';
 
-        // Try and locate the dSYM file on macOS
+        // Try and locate the dSYM file on Mac OS X
         Timer scoped_timer2 ("SymbolVendorMacOSX::CreateInstance () locate dSYM",
                              "SymbolVendorMacOSX::CreateInstance (module = %s) locate dSYM",
                              module_sp->GetFileSpec().GetPath().c_str());

lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp

@@ -1002,7 +1002,7 @@ SystemRuntimeMacOSX::GetPluginNameStatic()
 const char *
 SystemRuntimeMacOSX::GetPluginDescriptionStatic()
 {
-    return "System runtime plugin for macOS native libraries.";
+    return "System runtime plugin for Mac OS X native libraries.";
 }