[lldb] Fix typos in documentation

[kazutakahirata]

No description provided.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Kazu Hirata (kazutakahirata)

Changes

---

Full diff: https://github.com/llvm/llvm-project/pull/139839.diff

5 Files Affected:

• (modified) lldb/docs/resources/build.rst (+1-1)
• (modified) lldb/docs/resources/contributing.rst (+1-1)
• (modified) lldb/docs/resources/debugging.rst (+8-8)
• (modified) lldb/docs/resources/qemu-testing.rst (+1-1)
• (modified) lldb/docs/use/variable.rst (+1-1)

diff --git a/lldb/docs/resources/build.rst b/lldb/docs/resources/build.rst
index e59dcc1972418..480430fede928 100644
--- a/lldb/docs/resources/build.rst
+++ b/lldb/docs/resources/build.rst
@@ -100,7 +100,7 @@ Windows
 * The Active Template Library (ATL).
 * `GnuWin32 <http://gnuwin32.sourceforge.net/>`_ for CoreUtils and Make.
 * `Python 3 <https://www.python.org/downloads/windows/>`_.  Make sure to (1) get
-  the x64 variant if that's what you're targetting and (2) install the debug
+  the x64 variant if that's what you're targeting and (2) install the debug
   library if you want to build a debug lldb. The standalone installer is the
   easiest way to get the debug library.
 * `Python Tools for Visual Studio
diff --git a/lldb/docs/resources/contributing.rst b/lldb/docs/resources/contributing.rst
index d3d467533c9ea..48fd000765f66 100644
--- a/lldb/docs/resources/contributing.rst
+++ b/lldb/docs/resources/contributing.rst
@@ -39,7 +39,7 @@ in a few ways. The 2 main ones are:
 * `Use of asserts <https://llvm.org/docs/CodingStandards.html#assert-liberally>`_:
   See the :ref:`section below<Error Handling>`.
 
-For any other contradications, consider the
+For any other contradictions, consider the
 `golden rule <https://llvm.org/docs/CodingStandards.html#introduction>`_
 before choosing to update the style of existing code.
 
diff --git a/lldb/docs/resources/debugging.rst b/lldb/docs/resources/debugging.rst
index ba23759b44cf5..ee3e45a49cbde 100644
--- a/lldb/docs/resources/debugging.rst
+++ b/lldb/docs/resources/debugging.rst
@@ -130,7 +130,7 @@ The inferior will stop, you place the breakpoint and then ``continue``. Go back
 to the inferior and input the command that should trigger the breakpoint.
 
 If you are running debugger and inferior in the same window, input ``ctrl+c``
-instead of ``process interrupt`` and then folllow the rest of the steps.
+instead of ``process interrupt`` and then follow the rest of the steps.
 
 If you are doing this with ``lldb-server`` and find your breakpoint is never
 hit, check that you are breaking in code that is actually run by
@@ -187,7 +187,7 @@ predictable way, or change the prompt of one or both copies of ``lldb``.
 If you are debugging a scenario where the ``lldb-server`` starts in ``platform``
 mode, but you want to debug the ``gdbserver`` mode you'll have to work out what
 subprocess it's starting for the ``gdbserver`` part. One way is to look at the
-list of runninng processes and take the command line from there.
+list of running processes and take the command line from there.
 
 In theory it should be possible to use LLDB's
 ``target.process.follow-fork-mode`` or GDB's ``follow-fork-mode`` to
@@ -387,8 +387,8 @@ an issue or asking for help. This is simply inspiration.
 Reduction
 *********
 
-The first step is to reduce uneeded compexity where it is cheap to do so. If
-something is easily removed or frozen to a cerain value, do so. The goal is to
+The first step is to reduce unneeded complexity where it is cheap to do so. If
+something is easily removed or frozen to a certain value, do so. The goal is to
 keep the failure mode the same, with fewer dependencies.
 
 This includes, but is not limited to:
@@ -396,11 +396,11 @@ This includes, but is not limited to:
 * Removing test cases that don't crash.
 * Replacing dynamic lookups with constant values.
 * Replace supporting functions with stubs that do nothing.
-* Moving the test case to less unqiue system. If your machine has an exotic
+* Moving the test case to less unique system. If your machine has an exotic
   extension, try it on a readily available commodity machine.
 * Removing irrelevant parts of the test program.
 * Reproducing the issue without using the LLDB test runner.
-* Converting a remote debuging scenario into a local one.
+* Converting a remote debugging scenario into a local one.
 
 Now we hopefully have a smaller reproducer than we started with. Next we need to
 find out what components of the software stack might be failing.
@@ -578,14 +578,14 @@ Doing it this way instead of exactly copying what LLDB does will save a few
 ptrace calls. The AArch64 example program shows how to do this.
 
 * The inferior contains ``BRK #0`` then ``NOP``.
-* 2 4 byte instructins means 8 bytes of data to replace, which matches the
+* 2 4-byte instructions means 8 bytes of data to replace, which matches the
   minimum size you can write with ``PTRACE_POKETEXT``.
 * The inferior runs to the ``BRK``, which brings us into the debugger.
 * The debugger reads ``PC`` and writes ``NOP`` then ``NOP`` to the location
   pointed to by ``PC``.
 * The debugger then single steps the inferior to the next instruction
   (this is not required in this specific scenario, you could just continue but
-  it is included because this more cloesly matches what ``lldb`` does).
+  it is included because this more closely matches what ``lldb`` does).
 * The debugger then continues the inferior.
 * The inferior exits, and the whole program exits.
 
diff --git a/lldb/docs/resources/qemu-testing.rst b/lldb/docs/resources/qemu-testing.rst
index e102f84a1d31f..8571287a04262 100644
--- a/lldb/docs/resources/qemu-testing.rst
+++ b/lldb/docs/resources/qemu-testing.rst
@@ -156,7 +156,7 @@ certainly not forwarded. An example of this is shown below.
 
 ::
 
-  $ lldb-server plaform --server --listen 0.0.0.0:54321 --gdbserver-port 49140
+  $ lldb-server platform --server --listen 0.0.0.0:54321 --gdbserver-port 49140
 
 The result of this is that:
 
diff --git a/lldb/docs/use/variable.rst b/lldb/docs/use/variable.rst
index 3ad71cb93c51d..22c1fd64c4a96 100644
--- a/lldb/docs/use/variable.rst
+++ b/lldb/docs/use/variable.rst
@@ -961,7 +961,7 @@ printed one by one.
 [1] The `max_children` argument is optional (since lldb 3.8.0) and indicates the
 maximum number of children that lldb is interested in (at this moment). If the
 computation of the number of children is expensive (for example, requires
-travesing a linked list to determine its size) your implementation may return
+traversing a linked list to determine its size) your implementation may return
 `max_children` rather than the actual number. If the computation is cheap (e.g., the
 number is stored as a field of the object), then you can always return the true
 number of children (that is, ignore the `max_children` argument).