maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

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
This commit is contained in:
Jason Molenda 2016-06-23 04:24:16 +00:00
parent 5e65d79d48
commit 17b45390db
21 changed files with 32 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
lldb/.gitignore vendored
View File

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

6
lldb/docs/lldb-gdb-remote.txt
View File

@ -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

4
lldb/docs/testsuite/a-detailed-walkthrough.txt
View File

@ -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.

2
lldb/include/lldb/Symbol/CompactUnwindInfo.h
View File

@ -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.

2
lldb/include/lldb/Target/Thread.h
View File

@ -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.

2
lldb/source/Host/common/Editline.cpp
View File

@ -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

2
lldb/source/Host/macosx/HostInfoMacOSX.mm
View File

@ -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,

2
lldb/source/Plugins/ABI/MacOSX-arm/ABIMacOSX_arm.cpp
View File

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

2
lldb/source/Plugins/ABI/MacOSX-arm64/ABIMacOSX_arm64.cpp
View File

@ -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[] =
{

2
lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
View File

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

8
lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.cpp
View File

@ -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.";
}

6
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
View File

@ -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:
//

2
lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
View File

@ -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;

2
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
View File

@ -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();

4
lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
View File

@ -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);

4
lldb/source/Plugins/Platform/MacOSX/PlatformMacOSX.cpp
View File

@ -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.";
}
//------------------------------------------------------------------

2
lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp
View File

@ -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.

2
lldb/source/Plugins/Process/Utility/UnwindLLDB.cpp
View File

@ -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)

4
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
View File

@ -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.

2
lldb/source/Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.cpp
View File

@ -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());

2
lldb/source/Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.cpp
View File

@ -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.";
}