diff --git a/lldb/docs/python_api.md b/lldb/docs/python_api.md
new file mode 100644
index 0000000000000..46fe255cea388
--- /dev/null
+++ b/lldb/docs/python_api.md
@@ -0,0 +1,15 @@
+# LLDB Python API
+
+% The long list of "skip" filters out several global functions that are
+% generated by SWIG (but which are not useful as they are only the
+% backend for their respective static functions in the classes).
+
+```{eval-rst}
+.. automodapi:: lldb
+  :no-inheritance-diagram:
+  :skip: command
+  :skip: declaration
+  :skip: in_range
+  :skip: is_numeric_type
+  :skip: lldb_iter
+```
diff --git a/lldb/docs/python_api.rst b/lldb/docs/python_api.rst
deleted file mode 100644
index 6a95b36161b03..0000000000000
--- a/lldb/docs/python_api.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-LLDB Python API
-================================
-
-..
-  The long list of "skip" filters out several global functions that are
-  generated by SWIG (but which are not useful as they are only the
-  backend for their respective static functions in the classes).
-.. automodapi:: lldb
-  :no-inheritance-diagram:
-  :skip: command
-  :skip: declaration
-  :skip: in_range
-  :skip: is_numeric_type
-  :skip: lldb_iter
diff --git a/lldb/docs/python_extensions.rst b/lldb/docs/python_extensions.md
similarity index 69%
rename from lldb/docs/python_extensions.rst
rename to lldb/docs/python_extensions.md
index 8420187efcdcc..4dca2c04f600b 100644
--- a/lldb/docs/python_extensions.rst
+++ b/lldb/docs/python_extensions.md
@@ -1,47 +1,50 @@
-Python Extensions
-=================
+# Python Extensions
 
 LLDB provides scriptable extensions to augment the debugger's capabilities.
 This gives users the ability to tailor their debugging experience to their own needs.
 
 This page describes some of these scripting extensions:
 
-Operating System Thread Plugins
--------------------------------
+## Operating System Thread Plugins
 
+```{eval-rst}
 .. automodapi:: lldb.plugins.operating_system
     :no-heading:
     :skip: ScriptedThread
     :no-inheritance-diagram:
+```
 
-Scripted Frame Provider Plugins
--------------------------------
+## Scripted Frame Provider Plugins
 
+```{eval-rst}
 .. automodapi:: lldb.plugins.scripted_frame_provider
     :no-heading:
     :skip: ABCMeta
     :no-inheritance-diagram:
+```
 
-Scripted Process Plugins
--------------------------------
+## Scripted Process Plugins
 
+```{eval-rst}
 .. automodapi:: lldb.plugins.scripted_process
     :no-heading:
     :skip: ABCMeta
     :no-inheritance-diagram:
+```
 
-Scripted Platform Plugins
--------------------------------
+## Scripted Platform Plugins
 
+```{eval-rst}
 .. automodapi:: lldb.plugins.scripted_platform
     :no-heading:
     :skip: ABCMeta
     :no-inheritance-diagram:
+```
 
-Scripted Thread Plan Plugins
--------------------------------
+## Scripted Thread Plan Plugins
 
+```{eval-rst}
 .. automodapi:: lldb.plugins.scripted_thread_plan
     :no-heading:
     :no-inheritance-diagram:
-
+```
diff --git a/lldb/docs/resources/caveats.md b/lldb/docs/resources/caveats.md
new file mode 100644
index 0000000000000..d83abdeac4def
--- /dev/null
+++ b/lldb/docs/resources/caveats.md
@@ -0,0 +1,63 @@
+# Caveats
+
+(python_caveat)=
+
+## Python
+
+LLDB has a powerful scripting interface which is accessible through Python.
+Python is available either from within LLDB through a (interactive) script
+interpreter, or as a Python module which you can import from the Python
+interpreter.
+
+To make this possible, LLDB links against the Python shared library. Linking
+against Python comes with some constraints to be aware of.
+
+1. It is not possible to build and link LLDB against a Python 3 library and
+   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 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.
+3. To use third party Python packages from inside LLDB, you need to install
+   them using a utility (such as `pip`) from the same Python distribution as
+   the one used to build and link LLDB.
+
+The previous considerations are especially important during development, but
+apply to binary distributions of LLDB as well.
+
+### LLDB in Xcode on macOS
+
+Users of lldb in Xcode on macOS commonly run into these issues when they
+install Python, often unknowingly as a dependency pulled in by Homebrew or
+other package managers. The problem is the symlinks that get created in
+`/usr/local/bin`, which comes before `/usr/bin` in your path. You can use
+`which python3` to check to what it resolves.
+
+To be sure you use the Python that matches with the lldb in Xcode use `xcrun`
+or use the absolute path to the shims in `/usr/bin`.
+
+```
+$ xcrun python3
+$ /usr/bin/python3
+```
+
+Similarly, to install packages and be able to use them from within lldb, you'll
+need to install them with the matching `pip3`.
+
+```
+$ xcrun pip3
+$ /usr/bin/pip3
+```
+
+The same is true for Python 2. Although Python 2 comes with the operating
+system rather than Xcode, you can still use `xcrun` to launch the system
+variant.
+
+```
+$ xcrun python
+$ /usr/bin/python
+```
+
+Keep in mind that Python 2 is deprecated and no longer maintained. Future
+versions of macOS will not include Python 2.7.
diff --git a/lldb/docs/resources/caveats.rst b/lldb/docs/resources/caveats.rst
deleted file mode 100644
index a3dcf24a6c521..0000000000000
--- a/lldb/docs/resources/caveats.rst
+++ /dev/null
@@ -1,68 +0,0 @@
-Caveats
-=======
-
-.. _python_caveat:
-
-Python
-------
-
-LLDB has a powerful scripting interface which is accessible through Python.
-Python is available either from within LLDB through a (interactive) script
-interpreter, or as a Python module which you can import from the Python
-interpreter.
-
-To make this possible, LLDB links against the Python shared library. Linking
-against Python comes with some constraints to be aware of.
-
-1.  It is not possible to build and link LLDB against a Python 3 library and
-    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 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.
-
-3.  To use third party Python packages from inside LLDB, you need to install
-    them using a utility (such as ``pip``) from the same Python distribution as
-    the one used to build and link LLDB.
-
-The previous considerations are especially important during development, but
-apply to binary distributions of LLDB as well.
-
-LLDB in Xcode on macOS
-``````````````````````
-
-Users of lldb in Xcode on macOS commonly run into these issues when they
-install Python, often unknowingly as a dependency pulled in by Homebrew or
-other package managers. The problem is the symlinks that get created in
-``/usr/local/bin``, which comes before ``/usr/bin`` in your path. You can use
-``which python3`` to check to what it resolves.
-
-To be sure you use the Python that matches with the lldb in Xcode use ``xcrun``
-or use the absolute path to the shims in ``/usr/bin``.
-
-::
-
-   $ xcrun python3
-   $ /usr/bin/python3
-
-Similarly, to install packages and be able to use them from within lldb, you'll
-need to install them with the matching ``pip3``.
-
-::
-
-   $ xcrun pip3
-   $ /usr/bin/pip3
-
-The same is true for Python 2. Although Python 2 comes with the operating
-system rather than Xcode, you can still use ``xcrun`` to launch the system
-variant.
-
-::
-
-   $ xcrun python
-   $ /usr/bin/python
-
-Keep in mind that Python 2 is deprecated and no longer maintained. Future
-versions of macOS will not include Python 2.7.
diff --git a/lldb/docs/resources/contributing.rst b/lldb/docs/resources/contributing.md
similarity index 61%
rename from lldb/docs/resources/contributing.rst
rename to lldb/docs/resources/contributing.md
index 8da87684f39ee..c79ec46b7b5d5 100644
--- a/lldb/docs/resources/contributing.rst
+++ b/lldb/docs/resources/contributing.md
@@ -1,64 +1,53 @@
-Contributing
-============
+# Contributing
 
-Getting Started
----------------
+## Getting Started
 
-Please refer to the `LLVM Getting Started Guide
-<https://llvm.org/docs/GettingStarted.html>`_ for general information on how to
+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>`_ respectively.
+test LLDB can be found in the {doc}`build instructions <build>` and
+{doc}`test instructions <test>` respectively.
 
-Contributing to LLDB
---------------------
+## Contributing to LLDB
 
-Please refer to the `LLVM Developer Policy
-<https://llvm.org/docs/DeveloperPolicy.html>`_ for information about
+Please refer to the [LLVM Developer Policy](https://llvm.org/docs/DeveloperPolicy.html) for information about
 authoring and uploading a patch. LLDB differs from the LLVM Developer
 Policy in the following respects.
 
 For anything not explicitly listed here, assume that LLDB follows the LLVM
 policy.
 
-Coding Style
-++++++++++++
+### Coding Style
 
-LLDB's code style differs from `LLVM's coding style <https://llvm.org/docs/CodingStandards.html>`_
+LLDB's code style differs from [LLVM's coding style](https://llvm.org/docs/CodingStandards.html)
 in a few ways. The 2 main ones are:
 
-* `Variable and function naming <https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly>`_:
+- [Variable and function naming](https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly):
 
-  * Variables are ``snake_case``.
-
-  * Functions and methods are ``UpperCamelCase``.
-
-  * Static, global and member variables have ``s_``, ``g_`` and ``m_``
+  - Variables are `snake_case`.
+  - Functions and methods are `UpperCamelCase`.
+  - Static, global and member variables have `s_`, `g_` and `m_`
     prefixes respectively.
 
-* `Use of asserts <https://llvm.org/docs/CodingStandards.html#assert-liberally>`_:
-  See the :ref:`section below<Error Handling>`.
+- [Use of asserts](https://llvm.org/docs/CodingStandards.html#assert-liberally):
+  See the {ref}`section below<error-handling>`.
 
 For any other contradictions, consider the
-`golden rule <https://llvm.org/docs/CodingStandards.html#introduction>`_
+[golden rule](https://llvm.org/docs/CodingStandards.html#introduction)
 before choosing to update the style of existing code.
 
 All new code in LLDB should be formatted with clang-format. Existing code may
 not conform and should be updated prior to being modified. Bulk reformatting
 is discouraged.
 
-Test Infrastructure
-+++++++++++++++++++
+### Test Infrastructure
 
-Like LLVM it is important to submit tests with your patches, but note that  a
+Like LLVM it is important to submit tests with your patches, but note that a
 subset of LLDB tests (the API tests) use a different system. Refer to the
-`test documentation <test.html>`_ for more details and the
-`lldb/test <https://github.com/llvm/llvm-project/tree/main/lldb/test>`_ folder
+{doc}`test documentation <test>` for more details and the
+[lldb/test](https://github.com/llvm/llvm-project/tree/main/lldb/test) folder
 for examples.
 
-
-LLDB plugins and their dependencies
------------------------------------
+## LLDB plugins and their dependencies
 
 LLDB has a concept of *plugins*, which are used to provide abstraction
 boundaries over functionality that is specific to a certain architecture,
@@ -89,27 +78,25 @@ In cases such as these, direct dependencies are acceptable. However, to keep the
 dependency graph manageable, we still have some rules to govern these
 relationships:
 
-* All dependencies between plugins of the same kind must flow in the same
-  direction (if plugin ``A1`` depends on plugin ``B1``, then ``B2`` must not depend on
-  ``A2``)
-* Dependency graph of plugin kinds must not contain loops (dependencies like
-  ``A1->B1``, ``B2->C2`` and ``C3->A3`` are forbidden because they induce a cycle in
+- All dependencies between plugins of the same kind must flow in the same
+  direction (if plugin `A1` depends on plugin `B1`, then `B2` must not depend on
+  `A2`)
+- Dependency graph of plugin kinds must not contain loops (dependencies like
+  `A1->B1`, `B2->C2` and `C3->A3` are forbidden because they induce a cycle in
   the plugin kind graph even though the plugins themselves are acyclical)
 
-
 The first of these rules is checked via CMake scripts (using the
-``LLDB_ACCEPTABLE_PLUGIN_DEPENDENCIES`` property). Dependencies in this category
+`LLDB_ACCEPTABLE_PLUGIN_DEPENDENCIES` property). Dependencies in this category
 are expected and permitted (subject to other constraints such as that dependency
 making sense for the particular pair of plugins). Unfortunately, due to historic
 reasons, not all plugin dependencies follow this rule, which is why we have
-another category called ``LLDB_TOLERATED_PLUGIN_DEPENDENCIES``. New dependencies
+another category called `LLDB_TOLERATED_PLUGIN_DEPENDENCIES`. New dependencies
 are forbidden (even though they are accepted by CMake) and existing ones should
 be removed wherever possible.
 
-.. _Error handling:
+(error-handling)=
 
-Error handling and use of assertions in LLDB
---------------------------------------------
+## Error handling and use of assertions in LLDB
 
 Contrary to Clang, which is typically a short-lived process, LLDB
 debuggers stay up and running for a long time, often serving multiple
@@ -117,45 +104,41 @@ debug sessions initiated by an IDE. For this reason LLDB code needs to
 be extra thoughtful about how to handle errors. Below are a couple
 rules of thumb:
 
-* Invalid input.  To deal with invalid input, such as malformed DWARF,
+- Invalid input. To deal with invalid input, such as malformed DWARF,
   missing object files, or otherwise inconsistent debug info,
-  error handling types such as `llvm::Expected<T>
-  <https://llvm.org/doxygen/classllvm_1_1Expected.html>`_ or
-  ``std::optional<T>`` should be used. Functions that may fail
+  error handling types such as [llvm::Expected\<T>](https://llvm.org/doxygen/classllvm_1_1Expected.html) or
+  `std::optional<T>` should be used. Functions that may fail
   should return their result using these wrapper types instead of
   using a bool to indicate success. Returning a default value when an
   error occurred is also discouraged.
-
-* Assertions.  Assertions (from ``assert.h``) should be used liberally
-  to assert internal consistency.  Assertions shall **never** be
-  used to detect invalid user input, such as malformed DWARF.  An
+- Assertions. Assertions (from `assert.h`) should be used liberally
+  to assert internal consistency. Assertions shall **never** be
+  used to detect invalid user input, such as malformed DWARF. An
   assertion should be placed to assert invariants that the developer
   is convinced will always hold, regardless what an end-user does with
   LLDB. Because assertions are not present in release builds, the
   checks in an assertion may be more expensive than otherwise
   permissible. In combination with the LLDB test suite, assertions are
   what allows us to refactor and evolve the LLDB code base.
-
-* Logging. LLDB provides a very rich logging API. When recoverable
+- Logging. LLDB provides a very rich logging API. When recoverable
   errors cannot reasonably be surfaced to the end user, the error may
   be written to a topical log channel.
-
-* Soft assertions.  LLDB provides ``lldbassert()`` as a soft
+- Soft assertions. LLDB provides `lldbassert()` as a soft
   alternative to cover the middle ground of situations that indicate a
-  recoverable bug in LLDB.  When asserts are enabled ``lldbassert()``
-  behaves like ``assert()``. When asserts are disabled, it will print a
+  recoverable bug in LLDB. When asserts are enabled `lldbassert()`
+  behaves like `assert()`. When asserts are disabled, it will print a
   warning and encourage the user to file a bug report, similar to
   LLVM's crash handler, and then return execution. Use these sparingly
   and only if error handling is not otherwise feasible.
 
-.. note::
-
-  New code should not be using ``lldbassert()`` and existing uses should
-  be replaced by other means of error handling.
+:::{note}
+New code should not be using `lldbassert()` and existing uses should
+be replaced by other means of error handling.
+:::
 
-* Fatal errors.  Aborting LLDB's process using
-  ``llvm::report_fatal_error()`` or ``abort()`` should be avoided at all
-  costs.  It's acceptable to use ``llvm_unreachable()`` for actually
+- Fatal errors. Aborting LLDB's process using
+  `llvm::report_fatal_error()` or `abort()` should be avoided at all
+  costs. It's acceptable to use `llvm_unreachable()` for actually
   unreachable code such as the default in an otherwise exhaustive
   switch statement.
 
diff --git a/lldb/docs/resources/fuzzing.md b/lldb/docs/resources/fuzzing.md
new file mode 100644
index 0000000000000..13470f62b30f7
--- /dev/null
+++ b/lldb/docs/resources/fuzzing.md
@@ -0,0 +1,67 @@
+# Fuzzing
+
+## Overview
+
+LLDB has fuzzers that provide automated [fuzz testing](https://en.wikipedia.org/wiki/Fuzzing) for different components of LLDB. The fuzzers are built with [libFuzzer](https://llvm.org/docs/LibFuzzer.html) . Currently, there are fuzzers for target creation, LLDB's command interpreter and LLDB's expression evaluator.
+
+## Building the fuzzers
+
+Building the LLDB fuzzers requires a build configuration that has the address sanitizer and sanitizer coverage enabled. In addition to your regular CMake arguments, you will need these arguments to build the fuzzers:
+
+```
+-DLLVM_USE_SANITIZER='Address' \
+-DLLVM_USE_SANITIZE_COVERAGE=On \
+-DCLANG_ENABLE_PROTO_FUZZER=ON
+```
+
+More information on libFuzzer's sanitizer coverage is available here: [https://llvm.org/docs/LibFuzzer.html#fuzzer-usage](https://llvm.org/docs/LibFuzzer.html#fuzzer-usage)
+
+If you want to debug LLDB itself when you find a bug using the fuzzers, use the CMake option `-DCMAKE_BUILD_TYPE='RelWithDebInfo'`
+
+To build a fuzzer, run the desired ninja command for the fuzzer(s) you want to build:
+
+```
+$ ninja lldb-target-fuzzer
+$ ninja lldb-commandinterpreter-fuzzer
+$ ninja lldb-expression-fuzzer
+```
+
+Once built, the binaries for the fuzzers will exist in the `bin` directory of your build folder.
+
+## Continuous integration
+
+Currently, there are plans to integrate the LLDB fuzzers into the [OSS Fuzz](https://github.com/google/oss-fuzz) project for continuous integration.
+
+## Running the fuzzers
+
+If you want to run the fuzzers locally, you can run the binaries that were generated with ninja from the build directory:
+
+```
+$ ./bin/lldb-target-fuzzer
+$ ./bin/lldb-commandinterpreter-fuzzer
+$ ./bin/lldb-expression-fuzzer
+```
+
+This will run the fuzzer binaries directly, and you can use the [libFuzzer options](https://llvm.org/docs/LibFuzzer.html#options) to customize how the fuzzers are run.
+
+Another way to run the fuzzers is to use a ninja target that will both build the fuzzers and then run them immediately after. These custom targets run each fuzzer with command-line arguments that provide better fuzzing for the components being tested. Running the fuzzers this way will also create directories that will store any inputs that caused LLDB to crash, timeout or run out of memory. The directories are created for each fuzzer.
+
+To run the custom ninja targets, run the command for your desired fuzzer:
+
+```
+$ ninja fuzz-lldb-target
+$ ninja fuzz-lldb-commandinterpreter
+$ ninja fuzz-lldb-expression
+```
+
+## Investigating and reproducing bugs
+
+When the fuzzers find an input that causes LLDB to crash, timeout or run out of memory, the input is saved to a file in the build directory. When running the fuzzer binaries directly this input is stored in a file named `<crash/timeout/oom>-<hash>`.
+
+When running the fuzzers using the custom ninja targets shown above, the inputs will be stored in `f...
[truncated]