Bug 1714788 - Fixed more Sphinx warnings in 'mach doc' r=sylvestre DONTBUILD

Differential Revision: https://phabricator.services.mozilla.com/D117419

docs/contributing/debugging/debugging_a_minidump.rst

@@ -115,7 +115,7 @@ build Breakpad, the binary will be at
 path to a Linux minidump will generate a core file on stdout which can
 then be loaded in gdb as usual. You will need to manually download the
 matching Firefox binaries, but then you can use the :ref:`GDB Python
-script <Downloading_symbols_on_Linux_Mac_OS_X>` to download symbols.
+script <Downloading symbols on Linux / Mac OS X>` to download symbols.
 
 The ``minidump-2-core`` source does not currently handle processing
 minidumps from a different CPU architecture than the system it was

docs/contributing/debugging/debugging_on_macos.rst

@@ -53,7 +53,7 @@ try Server Builds
 
 In most cases, developers needing to debug a build as close as possible
 to the production environment should use a :ref:`try
-build <Try Server>`. These
+build <Pushing to Try>`. These
 builds enable Hardened Runtime and only differ from production builds in
 that they are not Notarized which should not otherwise affect
 functionality, (other than the ability to easily launch the browser on

docs/contributing/debugging/stacktrace_report.rst

@@ -94,6 +94,7 @@ Each file in this folder contains one submitted crash report ID. You can
 check the modified or creation time for each file to discern which crash
 reports are relevant to your bug report.
 
+.. _Alternative ways to get a stacktrace:
 
 Alternative ways to get a stacktrace
 ------------------------------------
@@ -105,7 +106,7 @@ will need to obtain a stacktrace manually:
 Windows
 ~~~~~~~
 
-See the article :ref:`Create a stacktrace with Windbg` for information
+See the article :ref:`Create a stacktrace with Windbg <How to get a stacktrace with WinDbg>` for information
 on how to do this.
 
 For a full process dump, see :ref:`How to get a process dump with Windows