first pass at multiple debug shells docs

docs/debugging.rst

@@ -115,6 +115,7 @@ to be installed)::
 Using other debugging tools
 ---------------------------
 
+
 ``org.freedesktop.Sdk`` also includes other debugging tools like
 `Valgrind <https://valgrind.org/>`_ which is useful to find memory leaks.
 Once inside the :ref:`debugging:Debug shell`, it can be run with::
@@ -131,6 +132,40 @@ access to ``--filesystem=/sys`` to run::
 
   $ flatpak run --command=perf --filesystem=/sys --filesystem=$(pwd) --devel $FLATPAK_ID record -v -- <command>
 
+
+
+Multiple Debug shells in one sandbox
+------------------------------------
+
+Sometimes it can be helpful to have multiple debugging shells at a time.
+
+For example, some debugging commands such as `dotnet-dump <https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dump>`_
+expect to be given an identifier for a running process that it will connect to for debugging.
+
+This essentially requires multiple instances of the :ref:`debugging:Debug shell`,
+one to run the app, and one for running the debugging tool.
+
+To accomplish this, locate either the instance or process ID of an existing debug shell with::
+
+  $ flatpak ps
+
+Then you can enter this same sandbox from a new terminal window using::
+
+  $ flatpak enter <instance id> /bin/bash
+
+
+Note that this second shell likely will not be configured identically to the original debug
+shell (for example it will likely have different environment variables such as PATH).
+
+
+You can check whether both shells are indeed in the same sandbox by `checking the namespaces <https://unix.stackexchange.com/a/382406>`_
+visible in each debug shell and verifying that they are the same.
+
+The easiest way to do this is to list the visible namespaces using::
+
+  $ lsns --type pid
+
+
 Creating a Debug extension
 ---------------------------