Rename MacOS X -> macOS where applicable.
llvm-svn: 360691
This commit is contained in:
Adrian Prantl
parent
bbe4ff10df
commit
19ae9d010d
|
|
@ -1086,7 +1086,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 Mac OS X process which has nothing mapped in the first
|
||||
For instance, with a macOS process which has nothing mapped in the first
|
||||
4GB of its address space, if we're asking about address 0x2,
|
||||
|
||||
qMemoryRegionInfo:2
|
||||
|
|
@ -1611,7 +1611,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 Mac OS X, lldb can read offset
|
||||
// stub. For instance, on some versions of macOS, 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
|
||||
|
|
@ -1620,7 +1620,7 @@ for this region.
|
|||
// jThreadExtendedInfo:{"plo_pthread_tsd_base_address_offset":0,"plo_pthread_tsd_base_offset":224,"plo_pthread_tsd_entry_size":8,"thread":612910}
|
||||
//
|
||||
// There are no requirements for what is included in the response. A simple
|
||||
// reply on a Mac OS X Yosemite / iOS 8 may include the pthread_t value, the
|
||||
// reply on a OS X Yosemite / iOS 8 may include the pthread_t value, the
|
||||
// Thread Specific Data (TSD) address, the dispatch_queue_t value if the thread
|
||||
// is associated with a GCD queue, and the requested Quality of Service (QoS)
|
||||
// information about that thread. For instance, a reply may look like:
|
||||
|
|
@ -1740,7 +1740,7 @@ for this region.
|
|||
// out of memory with generic read packets) but also adds additional information in the form of the
|
||||
// filename of the shared libraries (which is not available in the mach-o header/load commands.)
|
||||
//
|
||||
// An example using the Mac OS X 10.11 style call:
|
||||
// An example using the OS X 10.11 style call:
|
||||
//
|
||||
// LLDB SENDS: jGetLoadedDynamicLibrariesInfos:{"image_count":1,"image_list_address":140734800075128}
|
||||
// STUB REPLIES: ${"images":[{"load_address":4294967296,"mod_date":0,"pathname":"/tmp/a.out","uuid":"02CF262C-ED6F-3965-9E14-63538B465CFF","mach_header":{"magic":4277009103,"cputype":16777223,"cpusubtype":18446744071562067971,"filetype":2},"segments":{"name":"__PAGEZERO","vmaddr":0,"vmsize":4294967296,"fileoff":0,"filesize":0,"maxprot":0},{"name":"__TEXT","vmaddr":4294967296,"vmsize":4096,"fileoff":0,"filesize":4096,"maxprot":7},{"name":"__LINKEDIT","vmaddr":4294971392,"vmsize":4096,"fileoff":4096,"filesize":152,"maxprot":7}}]}#00
|
||||
|
|
@ -1797,7 +1797,7 @@ for this region.
|
|||
// would need to work correctly on this platform.
|
||||
//
|
||||
// PRIORITY TO IMPLEMENT
|
||||
// On Mac OS X 10.11, iOS 9, tvOS 9, watchOS 2 and older: Low. If this packet is absent,
|
||||
// On OS X 10.11, iOS 9, tvOS 9, watchOS 2 and older: Low. If this packet is absent,
|
||||
// lldb will read the Mach-O headers/load commands out of memory.
|
||||
// On macOS 10.12, iOS 10, tvOS 10, watchOS 3 and newer: High. If this packet is absent,
|
||||
// lldb will not know anything about shared libraries in the inferior, or where the main
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ and the working directory to point to binaries inside of the ninja tree.
|
|||
Building LLDB on macOS
|
||||
----------------------
|
||||
|
||||
There are two ways to build LLDB on Mac OS X: Using Xcode and using CMake
|
||||
There are two ways to build LLDB on macOS: Using Xcode and using CMake
|
||||
|
||||
**Preliminaries**
|
||||
|
||||
|
|
@ -122,13 +122,12 @@ There are two ways to build LLDB on Mac OS X: Using Xcode and using CMake
|
|||
|
||||
**Building LLDB with Xcode**
|
||||
|
||||
Building on Mac OS X with Xcode is as easy as downloading the code and building
|
||||
Building on macOS with Xcode is as easy as downloading the code and building
|
||||
the Xcode project or workspace:
|
||||
|
||||
* Download the lldb sources.
|
||||
* Follow the code signing instructions in ``lldb/docs/code-signing.txt``.
|
||||
* In Xcode 3.x: ``lldb/lldb.xcodeproj``, select the lldb-tool target, and build.
|
||||
* In Xcode 4.x: ``lldb/lldb.xcworkspace``, select the lldb-tool scheme, and build.
|
||||
* In Xcode, open ``lldb/lldb.xcworkspace``, select the lldb-tool scheme, and build.
|
||||
|
||||
**Building LLDB with CMake**
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ Reusability
|
|||
|
||||
The LLDB debugger APIs are exposed as a C++ object oriented interface in a
|
||||
shared library. The lldb command line tool links to, and uses this public API.
|
||||
On Mac OS X the shared library is exposed as a framework named LLDB.framework,
|
||||
On macOS the shared library is exposed as a framework named LLDB.framework,
|
||||
and unix systems expose it as lldb.so. The entire API is also then exposed
|
||||
through Python script bindings which allow the API to be used within the LLDB
|
||||
embedded script interpreter, and also in any python script that loads the
|
||||
|
|
@ -54,7 +54,7 @@ Platform Support
|
|||
LLDB is known to work on the following platforms, but ports to new platforms
|
||||
are welcome:
|
||||
|
||||
* Mac OS X desktop user space debugging for i386 and x86-64
|
||||
* macOS desktop user space debugging for i386 and x86-64
|
||||
* iOS simulator debugging on i386
|
||||
* iOS device debugging on ARM
|
||||
* Linux local user-space debugging for i386, x86-64 and PPC64le
|
||||
|
|
|
|||
|
|
@ -13,6 +13,6 @@ LLDB supports a broad variety of basic debugging features such as reading DWARF,
|
|||
* Debugger plug-ins implement the host and target specific functions required to debug.
|
||||
|
||||
* SWIG-generated script bridging allows Python to access and control the public API of the debugger library.
|
||||
* A remote protocol server, debugserver, implements Mac OS X debugging on i386 and x86-64.
|
||||
* A remote protocol server, debugserver, implements macOS debugging on i386 and x86-64.
|
||||
* A command line debugger - the lldb executable itself.
|
||||
* A framework API to the library.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ macOS
|
|||
|
||||
LLDB has matured a lot in the last year and can be used for C, C++ and
|
||||
Objective-C development for x86_64, i386 and ARM debugging. The entire public
|
||||
API is exposed though a framework on Mac OS X which is used by Xcode, the lldb
|
||||
API is exposed though a framework on macOS which is used by Xcode, the lldb
|
||||
command line tool, and can also be used by Python. The entire public API is
|
||||
exposed through script bridging which allows LLDB to use an embedded Python
|
||||
script interpreter, as well as having a Python module named "lldb" which can be
|
||||
|
|
@ -40,7 +40,7 @@ section below.
|
|||
Features Matrix
|
||||
---------------
|
||||
+--------------------------------+------------+-------------------------+--------------------------------------+----------------------+
|
||||
| Feature | FreeBSD | Linux | Mac OS X (i386/x86_64 and ARM/Thumb) | Windows (i386) |
|
||||
| Feature | FreeBSD | Linux | macOS (i386/x86_64 and ARM/Thumb) | Windows (i386) |
|
||||
| | (x86_64) | (x86_64 and PPC64le) | | |
|
||||
+================================+============+=========================+======================================+======================+
|
||||
| Backtracing | OK | OK | OK | OK |
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
Mac OS X provides an additional way to manipulate archived DWARF debug symbol
|
||||
macOS 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:
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ Execution Commands
|
|||
</tr>
|
||||
|
||||
<tr>
|
||||
<td class="header" colspan="2">Launch a process with arguments in new terminal window (Mac OS X only).</td>
|
||||
<td class="header" colspan="2">Launch a process with arguments in new terminal window (macOS only).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="content">
|
||||
|
|
@ -125,7 +125,7 @@ Execution Commands
|
|||
|
||||
<tr>
|
||||
<td class="header" colspan="2">Launch a process with arguments in existing terminal
|
||||
<cope>/dev/ttys006 (Mac OS X only).</cope>
|
||||
<cope>/dev/ttys006 (macOS only).</cope>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -1385,7 +1385,7 @@ Examining Thread State
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="header" colspan="2">Get information about a specific heap allocation (available on Mac OS X only).</td>
|
||||
<td class="header" colspan="2">Get information about a specific heap allocation (available on macOS only).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="content">
|
||||
|
|
@ -1401,7 +1401,7 @@ Examining Thread State
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="header" colspan="2">Get information about a specific heap allocation and cast the result to any dynamic type that can be deduced (available on Mac OS X only)</td>
|
||||
<td class="header" colspan="2">Get information about a specific heap allocation and cast the result to any dynamic type that can be deduced (available on macOS only)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="content">
|
||||
|
|
@ -1414,7 +1414,7 @@ Examining Thread State
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="header" colspan="2">Find all heap blocks that contain a pointer specified by an expression EXPR (available on Mac OS X only).</td>
|
||||
<td class="header" colspan="2">Find all heap blocks that contain a pointer specified by an expression EXPR (available on macOS only).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="content">
|
||||
|
|
@ -1427,7 +1427,7 @@ Examining Thread State
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="header" colspan="2">Find all heap blocks that contain a C string anywhere in the block (available on Mac OS X only).</td>
|
||||
<td class="header" colspan="2">Find all heap blocks that contain a C string anywhere in the block (available on macOS only).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="content">
|
||||
|
|
|
|||
|
|
@ -672,7 +672,7 @@ Using the lldb.py module in Python
|
|||
----------------------------------
|
||||
|
||||
LLDB has all of its core code build into a shared library which gets used by
|
||||
the lldb command line application. On Mac OS X this shared library is a
|
||||
the `lldb` command line application. On macOS this shared library is a
|
||||
framework: LLDB.framework and on other unix variants the program is a shared
|
||||
library: lldb.so. LLDB also provides an lldb.py module that contains the
|
||||
bindings from LLDB into Python. To use the LLDB.framework to create your own
|
||||
|
|
|
|||
|
|
@ -76,14 +76,14 @@ system. A list of available plug-ins can be obtained through platform list.
|
|||
local% lldb
|
||||
(lldb) platform list
|
||||
Available platforms:
|
||||
host: Local Mac OS X user platform plug-in.
|
||||
host: Local macOS user platform plug-in.
|
||||
remote-freebsd: Remote FreeBSD user platform plug-in.
|
||||
remote-linux: Remote Linux user platform plug-in.
|
||||
remote-netbsd: Remote NetBSD user platform plug-in.
|
||||
remote-windows: Remote Windows user platform plug-in.
|
||||
remote-android: Remote Android user platform plug-in.
|
||||
remote-ios: Remote iOS platform plug-in.
|
||||
remote-macosx: Remote Mac OS X user platform plug-in.
|
||||
remote-macosx: Remote macOS user platform plug-in.
|
||||
ios-simulator: iOS simulator platform plug-in.
|
||||
darwin-kernel: Darwin Kernel platform plug-in.
|
||||
tvos-simulator: Apple TV simulator platform plug-in.
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ section's file address:
|
|||
|
||||
|
||||
It is often much easier to specify the actual load location of each section by
|
||||
name. Crash logs on Mac OS X have a Binary Images section that specifies that
|
||||
name. Crash logs on macOS have a Binary Images section that specifies that
|
||||
address of the __TEXT segment for each binary. Specifying a slide requires
|
||||
requires that you first find the original (file) address for the __TEXT
|
||||
segment, and subtract the two values. If you specify the address of the __TEXT
|
||||
|
|
@ -161,7 +161,7 @@ shared libraries we want:
|
|||
(lldb) target modules add /usr/lib/system/libsystem_kernel.dylib
|
||||
|
||||
|
||||
If you have debug symbols in standalone files, such as dSYM files on Mac OS X,
|
||||
If you have debug symbols in standalone files, such as dSYM files on macOS,
|
||||
you can specify their paths using the --symfile option for the ``target create``
|
||||
(recent LLDB releases only) and ``target modules add`` commands:
|
||||
|
||||
|
|
@ -333,14 +333,14 @@ symbolicate an supplied address.
|
|||
|
||||
**lldb.macosx.crashlog**
|
||||
|
||||
lldb.macosx.crashlog is a package that is distributed on Mac OS X builds that
|
||||
lldb.macosx.crashlog is a package that is distributed on macOS builds that
|
||||
subclasses the above classes. This module parses the information in the Darwin
|
||||
crash logs and creates symbolication objects that represent the images, the
|
||||
sections and the thread frames for the backtraces. It then uses the functions
|
||||
in the lldb.utils.symbolication to symbolicate the crash logs.
|
||||
|
||||
This module installs a new ``crashlog`` command into the lldb command
|
||||
interpreter so that you can use it to parse and symbolicate Mac OS X crash
|
||||
interpreter so that you can use it to parse and symbolicate macOS crash
|
||||
logs:
|
||||
|
||||
::
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ breakpoints to have source line information that matches many header file
|
|||
paths.
|
||||
|
||||
If you set a file and line breakpoint using a full path to the source file,
|
||||
like Xcode does when setting a breakpoint in its GUI on Mac OS X when you click
|
||||
like Xcode does when setting a breakpoint in its GUI on macOS when you click
|
||||
in the gutter of the source view, this path must match the full paths in the
|
||||
debug information. If the paths mismatch, possibly due to passing in a resolved
|
||||
source file path that doesn't match an unresolved path in the debug
|
||||
|
|
|
|||
|
|
@ -746,7 +746,7 @@ container classes, regardless of the template arguments provided. The details
|
|||
for this are found at FormatManager.cpp
|
||||
|
||||
The regular expression language used by LLDB is the POSIX extended language, as
|
||||
defined by the Single UNIX Specification, of which Mac OS X is a compliant
|
||||
defined by the Single UNIX Specification, of which macOS is a compliant
|
||||
implementation.
|
||||
|
||||
Names Summaries
|
||||
|
|
@ -1032,7 +1032,7 @@ formatters for a same library or OS release.
|
|||
By default, several categories are created in LLDB:
|
||||
|
||||
- default: this is the category where every formatter ends up, unless another category is specified
|
||||
- objc: formatters for basic and common Objective-C types that do not specifically depend on Mac OS X
|
||||
- objc: formatters for basic and common Objective-C types that do not specifically depend on macOS
|
||||
- gnu-libstdc++: formatters for std::string, std::vector, std::list and std::map as implemented by libstdcpp
|
||||
- libcxx: formatters for std::string, std::vector, std::list and std::map as implemented by libcxx
|
||||
- system: truly basic types for which a formatter is required
|
||||
|
|
|
|||
Loading…
Reference in a new issue