[docs] Mention useful debugging tools with short blurbs about usage.

Based on Dave Lee's suggestion in:
swiftlang#35639 (review)

Author: varungandhi-apple

docs/DebuggingTheCompiler.md

@@ -634,16 +634,76 @@ and `-I /path/to/includedir` to include necessary swift modules and interfaces.
 
 ### Working with multi-architecture binaries
 
-In certain cases, one might be looking at multi-architecture binaries,
-such as [universal binaries](https://en.wikipedia.org/wiki/Universal_binary).
-By default `nm` will show symbols from all architectures, so a universal
-binary might look funny due to two copies of everything. Use `nm -arch`
-to look at a specific architecture:
+On macOS, one might be interested in debugging multi-architecture binaries
+such as [universal binaries][]. By default `nm` will show symbols from all
+architectures, so a universal binary might look funny due to two copies of
+everything. Use `nm -arch` to look at a specific architecture:
 
 ```
 nm -n -m -arch x86_64 path/to/libcake.dylib | swift demangle
 ```
 
+[universal binaries]: https://en.wikipedia.org/wiki/Universal_binary
+
+### Other helpful tools
+
+TODO: This section should mention information about non-macOS platforms:
+maybe we can have a table with rows for use cases and columns for
+platforms (macOS, Linux, Windows), and the cells would be tool names.
+We could also mention platforms next to the tool names.
+
+In the previous sub-sections, we've seen how using different tools can
+make working with assembly and object code much nicer. Here is a short
+listing of commonly used tools on macOS, along with some example use cases:
+
+- Miscellaneous:
+ - `strings`: Find printable strings in a binary file.
+  - Potential use cases: If you're building a binary in multiple configurations,
+    and forgot which binary corresponds to which configuration, you can look
+    through the output of `strings` to identify differences.
+- `c++filt`: The C++ equivalent of `swift-demangle`.
+  - Potential use cases: Looking at the generated code for the
+    Swift runtime, investigating C++ interop issues.
+
+- Linking:
+  - `libtool`: A tool to create static and dynamic libraries. Generally, it's
+    easier to instead ask `swiftc` to link files, but potentially handy as
+    a higher-level alternative to `ld`, `ar` and `lipo`.
+
+- Debug info:
+  - `dwarfdump`: Extract debug info in human-readable form.
+    - Potential use cases: If you want to quickly check if two binaries
+      are identical, you can compare their UUIDs. For on-disk binaries,
+      you can obtain the UUID using `dwarfdump --uuid` For binaries
+      loaded by a running application, you can obtain the UUID using
+      `image list` in LLDB.
+- `objdump`: Dump object files.
+   Some examples of using `objdump` are documented in the previous subsection.
+   If you have a Swift compiler build, you can use `llvm-objdump` from
+   `$LLVM_BUILD_DIR/bin` instead of using the system `objdump`.
+
+   Compared to other tools on this list, `objdump` packs a LOT of
+   functionality; it can show information about sections, relocations
+   and more. It also supports many flags to format and filter the output.
+
+- Linker information (symbol table, sections, binding):
+  - `nm`: Display symbol tables.
+    Some examples of using `nm` are documented in the previous subsection.
+  - `size`: Get high-level information about sections in a binary,
+    such as the sizes of sections and where they are located.
+  - `dyldinfo`: Display information used by dyld, such as which dylibs
+    an image depends on.
+  - `install_name_tool`: Change the name for a dynamic shared library,
+    and query or modify the runpath search paths (aka 'rpaths') it uses.
+
+- Multi-architecture binaries:
+  - `lipo`: A tool that can be used to create, inspect and dissect
+     [universal binaries][universal binaries].
+     - Potential use cases: If you have a universal binary on an
+       Apple Silicon Mac, but want to quickly test if the issue would reproduce
+       on `x86_64`, you can extract the `x86_64` slice by using `lipo`.
+       The `x86_64` binary will automatically run under Rosetta 2.
+
 ## Bisecting Compiler Errors
 
 ### Bisecting on SIL optimizer pass counts to identify optimizer bugs