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, 3 insertions, 3 deletions

diff --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 990fd889f8b..5f8242211b7 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/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,
-    // and we'll also need it for the macOS Core File process plugin.  When we have that we can also use it here.
+    // 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 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:
     //