[lldb] Fix typos in documentation (NFC)

lldb/docs/design/overview.rst

@@ -72,7 +72,7 @@ Core
 ----
 
 The Core source files contain basic functionality that is required in the
-debugger as well as the class represeting the debugger it self (Debugger). A
+debugger as well as the class representing the debugger itself (Debugger). A
 wide variety of classes are implemented:
 
 - Address (section offset addressing)

lldb/docs/doxygen.cfg.in

@@ -1434,7 +1434,7 @@ PERL_PATH              =
 #---------------------------------------------------------------------------
 
 # If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
-# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
+# generate an inheritance diagram (in HTML, RTF and LaTeX) for classes with base
 # or super classes. Setting the tag to NO turns the diagrams off. Note that
 # this option is superseded by the HAVE_DOT option below. This is only a
 # fallback. It is recommended to install and use dot, since it yields more

lldb/docs/lldb-for-gdb-users.txt

@@ -162,7 +162,7 @@ Current breakpoints:
   1.1: where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Projects/Sketch/SKTGraphicView.m:1405, address = 0x0000000100010d5b, resolved, hit count = 0 
 
 Note that each "logical" breakpoint can have multiple "locations".
-The logical breakpoint has an integer id, and it's locations have an
+The logical breakpoint has an integer id, and its locations have an
 id within their parent breakpoint (the two are joined by a ".",
 e.g. 1.1 in the example above.)  
 

lldb/docs/lldb-platform-packets.txt

@@ -113,7 +113,7 @@ incompatible with the flags that gdb specifies.
 //     3. {optional} working directory ascii-hex encoded
 //
 //  Response is F followed by the return value of the command (base 16),
-//  followed by a another number, followed by the output of the command
+//  followed by another number, followed by the output of the command
 /   in binary-escaped-data encoding.
 
 //----------------------------------------------------------------------

lldb/docs/python_api_enums.rst

@@ -496,7 +496,7 @@ limit the amount of information that gets parsed to only the
 information that is requested. These bits also can indicate what
 actually did get resolved during query function calls.
 
-Each definition corresponds to a one of the member variables
+Each definition corresponds to one of the member variables
 in this class, and requests that that item be resolved, or
 indicates that the member did get resolved.
 

lldb/docs/resources/build.rst

@@ -133,7 +133,7 @@ macOS
 Building LLDB with CMake
 ------------------------
 
-The LLVM project is migrating to a single monolithic respository for LLVM and
+The LLVM project is migrating to a single monolithic repository for LLVM and
 its subprojects. This is the recommended way to build LLDB. Check out the
 source-tree with git:
 

lldb/docs/resources/caveats.rst

@@ -21,7 +21,7 @@ against Python comes with some constraints to be aware of.
     use it from Python 2 and vice versa.
 
 2.  It is not possible to build and link LLDB against one distribution on
-    Python and use it through a interpreter coming from another distribution.
+    Python and use it through an interpreter coming from another distribution.
     For example, on macOS, if you build and link against Python from
     python.org, you cannot import the lldb module from the Python interpreter
     installed with Homebrew.

lldb/docs/resources/contributing.rst

@@ -8,7 +8,7 @@ Please refer to the `LLVM Getting Started Guide
 <https://llvm.org/docs/GettingStarted.html>`_ for general information on how to
 get started on the LLVM project. A detailed explanation on how to build and
 test LLDB can be found in the `build instructions <build.html>`_ and `test
-instructions <test.html>`_ respecitvely.
+instructions <test.html>`_ respectively.
 
 Contributing to LLDB
 --------------------

lldb/docs/resources/test.rst

@@ -365,7 +365,7 @@ Running tests in QEMU System Emulation Environment
 
 QEMU can be used to test LLDB in an emulation environment in the absence of
 actual hardware. `QEMU based testing <https://lldb.llvm.org/use/qemu-testing.html>`_
-page describes how to setup a emulation environment using QEMU helper scripts
+page describes how to setup an emulation environment using QEMU helper scripts
 found under llvm-project/lldb/scripts/lldb-test-qemu. These scripts currently
 work with Arm or AArch64, but support for other architectures can be added easily.
 

lldb/docs/use/python-reference.rst

@@ -787,7 +787,7 @@ Writing lldb frame recognizers in Python
 Frame recognizers allow for retrieving information about special frames based
 on ABI, arguments or other special properties of that frame, even without
 source code or debug info. Currently, one use case is to extract function
-arguments that would otherwise be unaccesible, or augment existing arguments.
+arguments that would otherwise be inaccessible, or augment existing arguments.
 
 Adding a custom frame recognizer is done by implementing a Python class and
 using the 'frame recognizer add' command. The Python class should have a

lldb/docs/use/tutorial.rst

@@ -246,7 +246,7 @@ breakpoint on all the methods that implement that selector in the classes in
 your program. Similarly, a file and line breakpoint might result in multiple
 locations if that file and line were inlined in different places in your code.
 
-The logical breakpoint has an integer id, and it's locations have an id within
+The logical breakpoint has an integer id, and its locations have an id within
 their parent breakpoint (the two are joined by a ".", e.g. 1.1 in the example
 above.)
 
@@ -324,7 +324,7 @@ do:
 Breakpoint Names
 ----------------
 
-Breakpoints carry two orthognal sets of information: one specifies where to set the breakpoint, and the other how to react when the breakpoint is hit. The latter set of information (e.g. commands, conditions, hit-count, auto-continue...) we call breakpoint options.
+Breakpoints carry two orthogonal sets of information: one specifies where to set the breakpoint, and the other how to react when the breakpoint is hit. The latter set of information (e.g. commands, conditions, hit-count, auto-continue...) we call breakpoint options.
 
 It is fairly common to want to apply one set of options to a number of breakpoints. For instance, you might want to check that self == nil and if it is, print a backtrace and continue, on a number of methods. One convenient way to do that would be to make all the breakpoints, then configure the options with: