GP-5227: Split launchers help apart.

Ghidra/Debug/Debugger-agent-dbgeng/build.gradle

@@ -13,6 +13,9 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
+// Not technically a Java project, but required to be a Help project
+apply from: "${rootProject.projectDir}/gradle/javaProject.gradle"
+apply from: "${rootProject.projectDir}/gradle/helpProject.gradle"
 apply from: "$rootProject.projectDir/gradle/distributableGhidraModule.gradle"
 apply from: "$rootProject.projectDir/gradle/nativeProject.gradle"
 apply from: "$rootProject.projectDir/gradle/hasPythonPackage.gradle"
@@ -20,6 +23,11 @@ apply from: "$rootProject.projectDir/gradle/hasPythonPackage.gradle"
 apply plugin: 'eclipse'
 eclipse.project.name = 'Debug Debugger-agent-dbgeng'
 
+dependencies {
+	// Only for Help :/
+	api project(':Debugger-rmi-trace')
+}
+
 ext.tlb = file("build/os/win_x86_64/dbgmodel.tlb")
 
 if ("win_x86_64".equals(getCurrentPlatformName())) {

Ghidra/Debug/Debugger-agent-dbgeng/certification.manifest

@@ -10,6 +10,8 @@ data/debugger-launchers/local-dbgeng-trace.bat||GHIDRA||||END|
 data/debugger-launchers/local-dbgeng.bat||GHIDRA||||END|
 data/debugger-launchers/remote-dbgeng.bat||GHIDRA||||END|
 data/debugger-launchers/svrcx-dbgeng.bat||GHIDRA||||END|
+src/main/help/help/TOC_Source.xml||GHIDRA||||END|
+src/main/help/help/topics/dbgeng/dbgeng.html||GHIDRA||||END|
 src/main/py/LICENSE||GHIDRA||||END|
 src/main/py/MANIFEST.in||GHIDRA||||END|
 src/main/py/README.md||GHIDRA||||END|

Ghidra/Debug/Debugger-agent-dbgeng/data/debugger-launchers/kernel-dbgeng.bat

@@ -8,7 +8,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#dbgeng_kernel
+::@help dbgeng#win_kernel
 ::@enum Connection:str Remote Local EXDI
 ::@env OPT_PYTHON_EXE:file!="python" "Python command" "The path to the Python 3 interpreter. Omit the full path to resolve using the system PATH."
 :: Use env instead of args, because "all args except first" is terrible to implement in batch

Ghidra/Debug/Debugger-agent-dbgeng/data/debugger-launchers/local-dbgeng-attach.bat

@@ -8,7 +8,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#dbgeng_attach
+::@help dbgeng#attach
 ::@env OPT_PYTHON_EXE:file!="python" "Python command" "The path to the Python 3 interpreter. Omit the full path to resolve using the system PATH."
 ::@env OPT_TARGET_PID:int=0 "Process id" "The target process id"
 ::@env OPT_ATTACH_FLAGS:int=0 "Attach flags" "Attach flags"

Ghidra/Debug/Debugger-agent-dbgeng/data/debugger-launchers/local-dbgeng-ext.bat

@@ -9,7 +9,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#dbgeng_ext
+::@help dbgeng#ext
 ::@env OPT_PYTHON_EXE:file!="python" "Python command" "The path to the Python 3 interpreter. Omit the full path to resolve using the system PATH."
 :: Use env instead of args, because "all args except first" is terrible to implement in batch
 ::@env OPT_TARGET_IMG:file="" "Image" "The target binary executable image"

Ghidra/Debug/Debugger-agent-dbgeng/data/debugger-launchers/local-dbgeng-trace.bat

@@ -8,7 +8,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#dbgeng_trace
+::@help dbgeng#ttd
 ::@env OPT_PYTHON_EXE:file!="python" "Python command" "The path to the Python 3 interpreter. Omit the full path to resolve using the system PATH."
 :: Use env instead of args, because "all args except first" is terrible to implement in batch
 ::@env OPT_TARGET_TRACE:file="" "Trace (.run)" "The target trace image"

Ghidra/Debug/Debugger-agent-dbgeng/data/debugger-launchers/local-dbgeng.bat

@@ -9,7 +9,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#dbgeng
+::@help dbgeng#local
 ::@env OPT_PYTHON_EXE:file!="python" "Python command" "The path to the Python 3 interpreter. Omit the full path to resolve using the system PATH."
 :: Use env instead of args, because "all args except first" is terrible to implement in batch
 ::@env OPT_TARGET_IMG:file="" "Image" "The target binary executable image"

Ghidra/Debug/Debugger-agent-dbgeng/data/debugger-launchers/remote-dbgeng.bat

@@ -8,7 +8,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#dbgeng_remote
+::@help dbgeng#remote
 ::@env OPT_PYTHON_EXE:file!="python" "Python command" "The path to the Python 3 interpreter. Omit the full path to resolve using the system PATH."
 ::@env OPT_CONNECT_STRING:str="" "Connection" "Connection-string arguments (a la .server)"
 ::@env WINDBG_DIR:dir="" "Path to dbgeng.dll directory" "Path containing dbgeng and associated DLLS (if not Windows Kits)."

Ghidra/Debug/Debugger-agent-dbgeng/data/debugger-launchers/svrcx-dbgeng.bat

@@ -9,7 +9,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#dbgeng_svrcx
+::@help dbgeng#svrcx
 ::@env OPT_PYTHON_EXE:file!="python" "Python command" "The path to the Python 3 interpreter. Omit the full path to resolve using the system PATH."
 :: Use env instead of args, because "all args except first" is terrible to implement in batch
 ::@env OPT_TARGET_IMG:str="" "Image" "The target binary executable image"

Ghidra/Debug/Debugger-agent-dbgeng/src/main/help/help/TOC_Source.xml

@@ -0,0 +1,31 @@
+<?xml version='1.0' encoding='ISO-8859-1'?>
+<!-- See Base's TOC_Source.xml for help -->
+<tocroot>
+	<tocref id="TraceRmiLauncherServicePlugin">
+		<tocdef id="dbgeng" text="WinDbg (dbgeng.dll) Integration"
+			target="help/topics/dbgeng/dbgeng.html">
+
+			<tocdef id="dbgeng_local" text="Local"
+				target="help/topics/dbgeng/dbgeng.html#local" />
+
+			<tocdef id="dbgeng_ext" text="Extended Local"
+				target="help/topics/dbgeng/dbgeng.html#ext" />
+
+			<tocdef id="dbgeng_attach" text="Attach"
+				target="help/topics/dbgeng/dbgeng.html#attach" />
+
+			<tocdef id="dbgeng_remote" text="Remote"
+				target="help/topics/dbgeng/dbgeng.html#remote" />
+
+			<tocdef id="dbgeng_svrcx" text="Process Server"
+				target="help/topics/dbgeng/dbgeng.html#svrcx" />
+
+			<tocdef id="dbgeng_win_kenel" text="Windows Kernel"
+				target="help/topics/dbgeng/dbgeng.html#win_kernel" />
+
+			<tocdef id="dbgeng_ttd" text="TTD (Time-Travel Debugging)"
+				target="help/topics/dbgeng/dbgeng.html#ttd" />
+
+		</tocdef>
+	</tocref>
+</tocroot>

Ghidra/Debug/Debugger-agent-dbgeng/src/main/help/help/topics/dbgeng/dbgeng.html

@@ -0,0 +1,277 @@
+<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
+
+<HTML>
+  <HEAD>
+    <META name="generator" content=
+    "HTML Tidy for Java (vers. 2009-12-01), see jtidy.sourceforge.net">
+
+    <TITLE>Debugger Launchers: Windows Debugger (WinDbg, dbgeng.dll)</TITLE>
+    <META http-equiv="Content-Type" content="text/html; charset=windows-1252">
+    <LINK rel="stylesheet" type="text/css" href="help/shared/DefaultStyle.css">
+  </HEAD>
+
+  <BODY lang="EN-US">
+    <H1>Debugger Launchers: Windows Debugger (WinDbg, dbgeng.dll)</H1>
+
+    <P>Integration with WinDbg is achieved by implementing a console debugger in Python 3 based on
+    <TT>dbgeng.dll</TT> (via pybag). This DLL represents the Microsoft Windows Debugger engine, and
+    so is best suited for debugging Windows user-space targets. This DLL also backs WinDbg and
+    several other debuggers on Windows. By default, the launcher will search for this DLL in an
+    installation of the Windows Debugging Kits version 10. If it does not find it there, it will
+    probably crash with a message in the Terminal.</P>
+
+    <P>The following launchers based on Microsoft's <TT>dbgeng.dll</TT> are included out of the
+    box:</P>
+
+    <H2><A name="local"></A>Local</H2>
+
+    <P>The plain "<TT>dbgeng</TT>" defaults to launching the current program as a user-mode process
+    on the local system. If there is no current program, this launcher cannot be used. Clearing the
+    <B>Image</B> option will cause this launcher to fail.</P>
+
+    <P>Please note on some system configurations, one of the debugger's dependencies
+    <TT>dbghelp.dll</TT> may get loaded from the system directory instead of from the WinDbg
+    installation, usually because a security product has pre-loaded it into the Python process. You
+    might work around this by copying the affected DLLs from your WinDbg installation into your
+    Python installation.</P>
+
+    <H3><A name="setup"></A>Setup</H3>
+
+    <P>Installing WinDbg is highly recommended. If you wish to forego installing WinDbg, you can
+    use the DLL provided with Windows, which is substantially less capable, by manually pointing
+    this connector to <TT>C:\Windows\system32</TT>. If you do this, some commands, e.g.
+    <TT>.server</TT>, will not be available.</P>
+
+    <P>If you have access to PyPI, setting up your Python 3 environment is done using Pip. Please
+    note the version specifier for Protobuf.</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+python3 -m pip install pybag protobuf==3.20.3
+</PRE>
+      </LI>
+    </UL>
+
+    <P>If you are offline, or would like to use our provided packages, we still use Pip, but with a
+    more complicated invocation:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+cd C:\path\to\ghidra_<EM>
+version</EM>\Ghidra\Debug
+python3 -m pip install --no-index -f Debugger-rmi-trace\pypkg\dist -f Debugger-agent-dbgeng\pypkg\dist pybag protobuf
+</PRE>
+      </LI>
+    </UL>
+
+    <P>If you get an import error regarding <TT>distutils</TT>, it is due to a transitive
+    dependency on a buggy version of <TT>capstone</TT>. Work around it by installing
+    <TT>setuptools</TT>.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B><TT>python</TT> command</B>: This is the command or path to the Python interpreter. It
+      must be version 3. Python 2 is not supported.</LI>
+
+      <LI><B>Image</B>: This is the path to the target binary image (EXE file). Ghidra will try to
+      fill this in based on information gathered when the current program was imported. If the file
+      exists and is executable on the local machine, it will be filled in automatically. Otherwise,
+      it is up to you to locate it. <B>NOTE:</B> If you have patched the current program database,
+      these changes are <EM>not</EM> applied to the target. You can either 1) apply the same
+      patches to the target once it is running, or 2) export a patched copy of your image and
+      direct this launcher to run it.</LI>
+
+      <LI><B>Arguments</B>: These are the command-line arguments to pass into the target process.
+      These are passed as is into WinDbg's "<TT>CreateProcess</TT>" function.</LI>
+
+      <LI><B>Use <TT>dbgmodel</TT></B>: If <TT>dbgmodel.dll</TT> is available on the system, this
+      launcher will use it to populate the trace's object model. Without that DLL, the launcher
+      will invent its own model, roughly approximating the same, using just the information
+      available from <TT>dbgeng.dll</TT>. Disabling this option will prevent the launcher from
+      using <TT>dbgmodel.dll</TT>, even when it is available.</LI>
+
+      <LI><B>Path to <TT>dbgeng.dll</TT> directory</B>: By default, the launcher allows the
+      underlying <TT>pybag</TT> package to locate the Windows Debugger DLLs. This is typically
+      found by examining the registry for a Windows Kits 10 installation. Otherwise, it may check
+      its typical installation directory. This will <EM>not</EM> search the Windows system
+      directory, but you can configure it manually here. This option allows you to override this
+      search. For example, if you have installed WinDbg Preview or later from the Microsoft Store
+      and wish to use its DLLs, you will need to fill in this option.</LI>
+    </UL>
+
+    <P>Once running, you are presented with a command-line interface in Ghidra's Terminal. This CLI
+    accepts your usual WinDbg (kd) commands. You can escape from this CLI and enter a Python 3 REPL
+    by entering "<TT>.exit</TT>". This is not an actual kd command, but our implementation
+    understands this to mean exit the kd REPL. From the Python 3 REPL, you can access the
+    underlying Python-based API <TT>pybag</TT>. This is an uncommon need, but may be useful for
+    diagnostics and/or workarounds. To re-enter the kd REPL, enter "<TT>repl()</TT>".
+    Alternatively, if you are trying to quit, but typed "<TT>.exit</TT>", just type
+    "<TT>quit()</TT>" to terminate the session.</P>
+
+    <H2><A name="ext"></A>Extended Local</H2>
+
+    <P>The "<TT>dbgeng-ext</TT>" launcher extends the base <TT>dbgeng</TT> launcher adding extra
+    options (a la <TT>IDebugClient</TT>'s <TT>CreateProcess2</TT>).</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Dir</B>: This is the starting directory for the process.</LI>
+
+      <LI><B>Env</B>: This is a composite string containg Environment Variable entries delineated
+      by '/0' separators. For example, you could redefine USERNAME and USERPROFILE with the entry
+      'USERNAME=SomeUser/0USERPROFILE=C:\Users\SomeUser'.</LI>
+
+      <LI><B>CreateFlags</B>: Flags used when creating the process, typically either
+      DEBUG_PROCESS(1) or DEBUG_ONLY_THIS_PROCESS(2) if you do not wish to follow spawned
+      processes. Other possible values are defined by processes.h's
+      CreateProcessCreationFlags.</LI>
+
+      <LI><B>CreateFlags (Engine)</B>: Engine-specific flags used when creating the process
+      (defined in dbgeng.h). Typically, these are set to 0.</LI>
+
+      <LI><B>VerifierFlags (Engine)</B>: Flags used by the Application Verifier. Typically unused,
+      but, if desired, CreateEngineFlags must include
+      DEBUG_ECREATE_PROCESS_USE_VERIFIER_FLAGS(2).</LI>
+    </UL>
+
+    <H2><A name="attach"></A>Attach</H2>
+
+    <P>This launcher allows the user to attach to a local running process. Options are the same as
+    those for the base dbgeng, except for ProcessId and AttachFlags</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>ProcessId</B>: The pid of the process you wish to attach to.</LI>
+
+      <LI><B>AttachFlags</B>: Flags used when attaching to the target process, typically
+      DEBUG_ATTACH_PROCESS(0). Other possible values are defined in dbgeng.h and determine whether
+      the attach should be invasive or not and the status of the process after attaching.</LI>
+    </UL>
+
+    <H2><A name="remote"></A>Remote</H2>
+
+    <P>This launcher connects to a remote debugger that has opened a port for remote control.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI>
+        <B>Connection</B>: This is the connection string specifying the transport options for
+        communicating with the remote debugger. A typical example might be
+        'tcp:port=12345,server=192.168.0.2' for a debugger that has issued the command 
+<PRE>
+.server tcp:port=12345
+</PRE>
+      </LI>
+    </UL>
+
+    <H2><A name="svrcx"></A>Process Server</H2>
+
+    <P>The "<TT>dbgeng-svrcx</TT>" launcher extends the base dbgeng launcher adding an option for
+    connecting through a remote process server.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI>
+        <B>Connection</B>: This is the connection string specifying the transport options for
+        communicating with the remote server. A typical example might be
+        'tcp:port=12345,server=192.168.0.2' for a process server launched on the machine at
+        192.168.0.2 using: 
+<PRE>
+        dbgsrv -t tcp:port=12345
+       
+</PRE>
+      </LI>
+    </UL>
+
+    <H2><A name="win_kernel"></A>Windows Kernel</H2>
+
+    <P>This version of the dbgeng should be used for kernel-debugging of a remote machine. Options
+    are the same as the base dbgeng, except for the connection-string arguments. For remote
+    debugging, the target machine should be booted with the appropriate options, set using BCDEDIT
+    or the equivalent, such as:</P>
+
+    <UL style='list-style-type: none'>
+      <LI>
+<PRE>
+bcdedit /debug ON
+bdcedit /dbgsettings NET HOSTIP:IP PORT:54321 KEY:1.1.1.1
+</PRE>
+      </LI>
+    </UL>
+
+    <P>where IP= the address of the machine runing Ghidra.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Arguments</B>: This is the connection string specifying the transport options for
+      communicating with the remote target. A typical example might be
+      'net:port=54321,key=1.1.1.1'.'</LI>
+    </UL>
+
+    <UL>
+      <LI><B>Type</B>: The type of kernel connection, either "Remote", "Local", or "EXDI".
+      "Remote", the most common type, indicates two-machine debugging over various possible
+      connection media, e.g. Ethernet, serial, USB, etc. "Local" is used for limited introspection
+      into the target on which the debugger is running. "EXDI" is arguably the most exotic type -
+      it essentially simulates the normal "Remote" connection using the gdb Remote Serial Protocol.
+      It can be used when connecting to gdbstubs in platforms, such as QEMU, VMWare, Trace32,
+      etc.</LI>
+    </UL>
+
+    <H3>EXDI</H3>
+
+    <P>Setup for EXDI connections is fairly complicated and difficult to get correct. The argument
+    string typically should be something like:</P>
+
+    <UL style='list-style-type: none'>
+      <LI>
+<PRE>
+exdi:CLSID={29f9906e-9dbe-4d4b-b0fb-6acf7fb6d014},Kd=Guess,DataBreaks=Exdi
+</PRE>
+      </LI>
+    </UL>
+
+    <P>The CLSID here should match the CLSID in the <B>exdiConfigData.xml</B> file in the debugger
+    architectural directory. If windbg has been run using EXDI at some point, there will also be an
+    entry in the System Registry for this CLSID. The InprocServer32 subentry for this CLSID in the
+    Registry should point to a copy of ExdiGdbSrv.dll, typically the one in the same directory.
+    This DLL must reside somewhere that the debugger has permission to load from, i.e. not in the
+    WindowsApps directory tree. The <B>exdiConfigData</B> file should be configured for the target
+    you're using. We heavily recommend using <B>displayCommPackets==yes</B>, as many of the tasks
+    take considerable time, and this is the only indicator of progress.</P>
+
+    <P>The <B>Kd=Guess</B> parameter causes the underlying engine to scan memory for the kernel's
+    base address, which will probably not be provided by the gdbstub. (<B>Kd=NtBaseAddr</B> is also
+    a valid option, as is eliminating the parameter, but, currently, we have no idea how to point
+    the configuration at a correct value. Using this option will cause the load to spin
+    pointlessly.) If you can, we highly recommend breaking the target near the base address, as the
+    search proceeds down through memory starting at the current program counter. If the difference
+    between the PC and the base address is large, the loading process will punt before useful
+    values are detected. If anyone understand how to extend this search (or knows how to set the
+    base address to sidestep the scan), we would really love some guidance.</P>
+
+    <H2><A name="ttd"></A>TTD (Time-Travel Debugging)</H2>
+
+    <P>This is a nascent extension to our launcher for the Windows Debugger. The launcher itself
+    functions, but lacks full integration. In particular, Ghidra's concept of time is not mapped
+    directly to the TTD concept of time. TTD uses a major/minor scheme for ordering events, where
+    the major index changes when TTD must record a change in state. Events, including thread
+    creation/termination, module loads/unloads, syscalls, and other asynchronous changes, merit new
+    major indices. When you step forward or backward in a trace, the dbgeng API will increment and
+    decrement correspondingly. Ghidra, on the other hand, will only increment.</P>
+
+    <H3>Options</H3>
+
+    <P>This launcher has basically the same options as the WinDbg launcher, except that arguments
+    are not included and the DLL path must contain <TT>TTDReplay.dll</TT> and the scripts that
+    implement TTD. These are most easily obtained by installing WinDbg Preview or later.</P>
+  </BODY>
+</HTML>

Ghidra/Debug/Debugger-agent-drgn/build.gradle

@@ -13,8 +13,16 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
+// Not technically a Java project, but required to be a Help project
+apply from: "${rootProject.projectDir}/gradle/javaProject.gradle"
+apply from: "${rootProject.projectDir}/gradle/helpProject.gradle"
 apply from: "$rootProject.projectDir/gradle/distributableGhidraModule.gradle"
 apply from: "$rootProject.projectDir/gradle/hasPythonPackage.gradle"
 
 apply plugin: 'eclipse'
 eclipse.project.name = 'Debug Debugger-agent-drgn'
+
+dependencies {
+	// Only for Help :/
+	api project(':Debugger-rmi-trace')
+}

Ghidra/Debug/Debugger-agent-drgn/certification.manifest

@@ -4,6 +4,8 @@
 Module.manifest||GHIDRA||||END|
 README.md||GHIDRA||||END|
 build.gradle||GHIDRA||||END|
+src/main/help/help/TOC_Source.xml||GHIDRA||||END|
+src/main/help/help/topics/drgn/drgn.html||GHIDRA||||END|
 src/main/py/LICENSE||GHIDRA||||END|
 src/main/py/MANIFEST.in||GHIDRA||||END|
 src/main/py/README.md||GHIDRA||||END|

Ghidra/Debug/Debugger-agent-drgn/data/debugger-launchers/core-drgn.sh

@@ -24,7 +24,7 @@
 #@desc </body></html>
 #@menu-group drgn
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#drgn-core
+#@help drgn#core
 #@env OPT_TARGET_IMG:file!="" "Core dump" "The target core dump"
 
 export OPT_TARGET_KIND="coredump" 

Ghidra/Debug/Debugger-agent-drgn/data/debugger-launchers/kernel-drgn.sh

@@ -24,7 +24,7 @@
 #@desc </body></html>
 #@menu-group drgn
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#drgn-kernel
+#@help drgn#linux_kernel
 
 export OPT_TARGET_KIND="kernel" 
 sudo -E drgn ../support/local-drgn.py

Ghidra/Debug/Debugger-agent-drgn/data/debugger-launchers/local-drgn.sh

@@ -24,7 +24,7 @@
 #@desc </body></html>
 #@menu-group drgn
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#drgn
+#@help drgn#attach
 #@env OPT_TARGET_PID:int=44068 "PID" "The target's process id"
 
 export OPT_TARGET_KIND="user" 

Ghidra/Debug/Debugger-agent-drgn/src/main/help/help/TOC_Source.xml

@@ -0,0 +1,19 @@
+<?xml version='1.0' encoding='ISO-8859-1'?>
+<!-- See Base's TOC_Source.xml for help -->
+<tocroot>
+	<tocref id="TraceRmiLauncherServicePlugin">
+		<tocdef id="drgn" text="drgn Integration"
+			target="help/topics/drgn/drgn.html">
+
+			<tocdef id="drgn_attach" text="Attach"
+				target="help/topics/drgn/drgn.html#attach" />
+
+			<tocdef id="drgn_core" text="Core Dump"
+				target="help/topics/drgn/drgn.html#attach" />
+
+			<tocdef id="linux_kernel" text="Linux Kernel"
+				target="help/topics/drgn/drgn.html#attach" />
+
+		</tocdef>
+	</tocref>
+</tocroot>

Ghidra/Debug/Debugger-agent-drgn/src/main/help/help/topics/drgn/drgn.html

@@ -0,0 +1,78 @@
+<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
+
+<HTML>
+  <HEAD>
+    <META name="generator" content=
+    "HTML Tidy for Java (vers. 2009-12-01), see jtidy.sourceforge.net">
+
+    <TITLE>Debugger Launchers: drgn</TITLE>
+    <META http-equiv="Content-Type" content="text/html; charset=windows-1252">
+    <LINK rel="stylesheet" type="text/css" href="help/shared/DefaultStyle.css">
+  </HEAD>
+
+  <BODY lang="EN-US">
+    <H1><A name="plugin"></A>Debugger Launchers: drgn</H1>
+
+    <P>The following launchers uses Meta's <B>drgn</B> engine to explore various targets:</P>
+
+    <H2><A name="attach"></A>Attach</H2>
+
+    <P>The "<TT>drgn</TT>" launcher attaches to a running process via the Linux "/proc/pid"
+    interface.</P>
+
+    <H3>Setup</H3>
+
+    <P>You must have Meta's <B>drgn</B> installed on the local system. The default behavior assumes
+    you do NOT need root access to attach to a running process, i.e. it assumes you have run the
+    command:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+echo 0 &gt; /proc/sys/kernel/yama/ptrace_scope
+</PRE>
+      </LI>
+    </UL>
+
+    <P>using root privileges at some point. Alternately, you can prepend "sudo -E" to the drgn
+    invocation line in "local-drgn.sh"". Note: <B>drgn</B> does not currently support stack
+    unwinding or register access for user-mode access to running processes.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>PID</B>: The running process's id</LI>
+    </UL>
+
+    <H2><A name="core"></A>Core Dump</H2>
+
+    <P>This launcher loads a Linux core dump.</P>
+
+    <H3>Setup</H3>
+
+    <P>You must have Meta's <B>drgn</B> installed on the local system. No other setup is required.
+    Note: Core dumps may or may not include memory, so the Dynamic Listing may or may not be
+    populated.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Core dump</B>: The core-dump file</LI>
+    </UL>
+
+    <H2><A name="linux_kernel"></A>Linux Kernel</H2>
+
+    <P>This launcher attaches to a Linux kernel via the "/proc/kcore" interface.</P>
+
+    <H3>Setup</H3>
+
+    <P>You must have Meta's <B>drgn</B> installed on the local system. No other setup is required.
+    Note: requires root access - you will be prompted for a password in the Terminal.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>None</B></LI>
+    </UL>
+  </BODY>
+</HTML>

Ghidra/Debug/Debugger-agent-gdb/build.gradle

@@ -13,8 +13,16 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
+// Not technically a Java project, but required to be a Help project
+apply from: "${rootProject.projectDir}/gradle/javaProject.gradle"
+apply from: "${rootProject.projectDir}/gradle/helpProject.gradle"
 apply from: "$rootProject.projectDir/gradle/distributableGhidraModule.gradle"
 apply from: "$rootProject.projectDir/gradle/hasPythonPackage.gradle"
 
 apply plugin: 'eclipse'
 eclipse.project.name = 'Debug Debugger-agent-gdb'
+
+dependencies {
+	// Only for Help :/
+	api project(':Debugger-rmi-trace')
+}

Ghidra/Debug/Debugger-agent-gdb/certification.manifest

@@ -11,6 +11,9 @@ data/scripts/fallback_info_proc_mappings.gdb||GHIDRA||||END|
 data/scripts/fallback_maintenance_info_sections.gdb||GHIDRA||||END|
 data/scripts/getpid-linux-i386.gdb||GHIDRA||||END|
 data/scripts/wine32_info_proc_mappings.gdb||GHIDRA||||END|
+src/main/help/help/TOC_Source.xml||GHIDRA||||END|
+src/main/help/help/topics/gdb/gdb.html||GHIDRA||||END|
+src/main/help/help/topics/gdb/images/GdbLauncher.png||GHIDRA||||END|
 src/main/py/LICENSE||GHIDRA||||END|
 src/main/py/MANIFEST.in||GHIDRA||||END|
 src/main/py/README.md||GHIDRA||||END|

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/local-gdb.bat

@@ -9,7 +9,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#gdb
+::@help gdb#local
 ::@enum StartCmd:str run start starti
 ::@enum Endian:str auto big little
 ::@env OPT_TARGET_IMG:file="" "Image" "The target binary executable image"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/local-gdb.sh

@@ -25,7 +25,7 @@
 #@desc </body></html>
 #@menu-group local
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#gdb
+#@help gdb#local
 #@enum StartCmd:str run start starti
 #@enum Endian:str auto big little
 #@arg :file "Image" "The target binary executable image, empty for no target"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/local-rr.sh

@@ -24,7 +24,7 @@
 #@desc </body></html>
 #@menu-group local
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#gdb_rr
+#@help gdb#rr
 #@enum StartCmd:str run start starti
 #@enum Endian:str auto big little
 #@arg :file "Trace Dir" "The target trace directory (e.g. .local/share/rr/trace)"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/qemu-gdb.sh

@@ -26,7 +26,7 @@
 #@desc </body></html>
 #@menu-group cross
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#gdb_qemu
+#@help gdb#qemu
 #@enum Endian:str auto big little
 #@arg :file! "Image" "The target binary executable image"
 #@args "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/qemu-sys-gdb.bat

@@ -10,7 +10,7 @@
 ::@desc </body></html>
 ::@menu-group cross
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#gdb_qemu
+::@help gdb#qemu
 ::@enum Endian:str auto big little
 ::@env OPT_TARGET_IMG:file!="" "Image" "The target binary executable image"
 ::@env GHIDRA_LANG_EXTTOOL_qemu_system:file="" "QEMU command" "The path to qemu-system for the target architecture."

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/qemu-sys-gdb.sh

@@ -26,7 +26,7 @@
 #@desc </body></html>
 #@menu-group cross
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#gdb_qemu
+#@help gdb#qemu
 #@enum Endian:str auto big little
 #@arg :file! "Image" "The target binary executable image"
 #@env GHIDRA_LANG_EXTTOOL_qemu_system:file="" "QEMU command" "The path to qemu-system for the target architecture."

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/remote-gdb.bat

@@ -8,7 +8,7 @@
 ::@desc </body></html>
 ::@menu-group remote
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#gdb_remote
+::@help gdb#remote
 ::@enum TargetType:str remote extended-remote
 ::@enum Endian:str auto big little
 ::@env OPT_TARGET_TYPE:TargetType="remote" "Target" "The type of remote target"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/remote-gdb.sh

@@ -24,7 +24,7 @@
 #@desc </body></html>
 #@menu-group remote
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#gdb_remote
+#@help gdb#remote
 #@enum TargetType:str remote extended-remote
 #@enum Endian:str auto big little
 #@env OPT_TARGET_TYPE:TargetType="remote" "Target" "The type of remote target"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/ssh-gdb.bat

@@ -10,7 +10,7 @@
 ::@desc </body></html>
 ::@menu-group remote
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#gdb_ssh
+::@help gdb#ssh
 ::@enum StartCmd:str run start starti
 ::@enum Endian:str auto big little
 ::@env OPT_TARGET_IMG:str="" "Image" "The target binary executable image on the remote system"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/ssh-gdb.sh

@@ -26,7 +26,7 @@
 #@desc </body></html>
 #@menu-group remote
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#gdb_ssh
+#@help gdb#ssh
 #@enum StartCmd:str run start starti
 #@enum Endian:str auto big little
 #@arg :str "Image" "The target binary executable image on the remote system"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/ssh-gdbserver.bat

@@ -10,7 +10,7 @@
 ::@desc </body></html>
 ::@menu-group remote
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#gdb_gdbserver_ssh
+::@help gdb#gdbserver_ssh
 ::@enum Endian:str auto big little
 ::@env OPT_TARGET_IMG:str!="" "Image" "The target binary executable image on the remote system"
 ::@env OPT_TARGET_ARGS:str="" "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/ssh-gdbserver.sh

@@ -26,7 +26,7 @@
 #@desc </body></html>
 #@menu-group remote
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#gdb_gdbserver_ssh
+#@help gdb#gdbserver_ssh
 #@enum Endian:str auto big little
 #@arg :str! "Image" "The target binary executable image on the remote system"
 #@args "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-agent-gdb/data/debugger-launchers/wine-gdb.sh

@@ -25,7 +25,7 @@
 #@desc </body></html>
 #@menu-group cross
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#gdb_wine
+#@help gdb#wine
 #@enum Endian:str auto big little
 #@arg :file! "Image" "The target binary executable image"
 #@args "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-agent-gdb/src/main/help/help/TOC_Source.xml

@@ -0,0 +1,31 @@
+<?xml version='1.0' encoding='ISO-8859-1'?>
+<!-- See Base's TOC_Source.xml for help -->
+<tocroot>
+	<tocref id="TraceRmiLauncherServicePlugin">
+		<tocdef id="gdb" text="GDB Integration"
+			target="help/topics/gdb/gdb.html">
+
+			<tocdef id="gdb_local" text="Local"
+				target="help/topics/gdb/gdb.html#local" />
+
+			<tocdef id="gdb_ssh" text="Via SSH"
+				target="help/topics/gdb/gdb.html#ssh" />
+
+			<tocdef id="gdb_gdbserver_ssh" text="gdbserver via SSH"
+				target="help/topics/gdb/gdb.html#gdbserver_ssh" />
+
+			<tocdef id="gdb_qemu" text="QEMU"
+				target="help/topics/gdb/gdb.html#qemu" />
+
+			<tocdef id="gdb_wine" text="Wine"
+				target="help/topics/gdb/gdb.html#wine" />
+
+			<tocdef id="gdb_remote" text="Remote"
+				target="help/topics/gdb/gdb.html#remote" />
+
+			<tocdef id="gdb_rr" text="rr"
+				target="help/topics/gdb/gdb.html#rr" />
+
+		</tocdef>
+	</tocref>
+</tocroot>

Ghidra/Debug/Debugger-agent-gdb/src/main/help/help/topics/gdb/gdb.html

@@ -0,0 +1,439 @@
+<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
+
+<HTML>
+  <HEAD>
+    <META name="generator" content=
+    "HTML Tidy for Java (vers. 2009-12-01), see jtidy.sourceforge.net">
+
+    <TITLE>Debugger Launchers: GDB</TITLE>
+    <META http-equiv="Content-Type" content="text/html; charset=windows-1252">
+    <LINK rel="stylesheet" type="text/css" href="help/shared/DefaultStyle.css">
+  </HEAD>
+
+  <BODY lang="EN-US">
+    <H1>Debugger Launchers: GDB</H1>
+
+    <P>Integration with GDB is achieved using a Python-based plugin for GDB. It is well-suited for
+    debuging Linux user-space targets, many embedded systems, and sometimes Windows user-space
+    targets. Please note you may need to obtain a properly-configured build of GDB for your target.
+    If you are working with an embedded system, it is probably safest to install the "multiarch"
+    build of GDB from your package manager.</P>
+
+    <P>The following launchers based on GDB (GNU Debugger) are included out of the box:</P>
+
+    <H2><A name="local"></A>Local</H2>
+
+    <P>The plain "<TT>gdb</TT>" launch script defaults to launching the current program as a
+    user-mode process on the local system. If there is no current program, or if you clear the
+    <B>Image</B> option, this launcher will only start <TT>gdb</TT> and get it connected to a
+    Ghidra trace. You may then manually start or connect to your target. Note that this may also
+    require manual mapping of your program database(s) to the target memory.</P>
+
+    <H3><A name="setup"></A>Setup</H3>
+
+    <P>You must have GDB installed on the local system, and it must embed the Python 3 interpreter.
+    If you have access to PyPI, setting up your Python 3 environment is done using Pip. Please note
+    the version specifier for Protobuf.</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+python3 -m pip install psutil protobuf==3.20.3
+</PRE>
+      </LI>
+    </UL>
+
+    <P>If you are offline, or would like to use our provided packages, we still use Pip, but with a
+    more complicated invocation:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+cd /path/to/ghidra_<EM>
+version</EM>/Ghidra/Debug
+python3 -m pip install --no-index -f Debugger-rmi-trace/pypkg/dist -f Debugger-agent-gdb/pypkg/dist psutil protobuf
+</PRE>
+      </LI>
+    </UL>
+
+    <P>Beware that GDB may embed a different Python interpreter than your system's default. If you
+    are still getting import errors, check the version that GDB embeds:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+(bash)$ gdb
+(gdb) python-interactive
+&gt;&gt;&gt; import sys
+&gt;&gt;&gt; sys.version
+</PRE>
+      </LI>
+    </UL>
+
+    <P>Note the version and ensure that you are invoking Pip with that version. Supposing
+    <TT>sys.version</TT> indicates 3.10, you should invoke Pip using <TT>python3.10 -m
+    pip</TT>.</P>
+
+    <P><B>Warning</B>: Modern Linux distributions are beginning to adopt PEP 668, which prevents
+    installation of Python packages outside of a virtual environment (venv) <EM>even for non-root
+    user accounts</EM>. Unfortunately, <TT>gdb</TT> does not seem to honor the currently activated
+    venv, and so such configurations are not officially supported. You may be able to work around
+    this by modifying the <TT>PYTHONPATH</TT> lines of the launcher script, but your mileage may
+    vary. For now, we recommend using the <TT>--break-system-packages</TT> argument with Pip.</P>
+
+    <H3>Options</H3>
+
+    <DIV class="image">
+      <IMG alt="" src="images/GdbLauncher.png">
+    </DIV>
+
+    <UL>
+      <LI><B>Image</B>: This is the path to the target binary image (ELF). Ghidra will try to fill
+      this in based on information gathered when the current program was imported. If the file
+      exists and is executable on the local machine, it will be filled in automatically. Otherwise,
+      it is up to you to locate it. <B>NOTE:</B> If you have patched the current program database,
+      these changes are <EM>not</EM> applied to the target. You can either 1) apply the same
+      patches to the target once it is running, or 2) export a patched copy of your image and
+      direct this launcher to run it.</LI>
+
+      <LI><B>Arguments</B>: These are the command-line arguments to pass into the target process.
+      These are passed as is to GDB's "<TT>set args ...</TT>" command.</LI>
+
+      <LI><B><TT>gdb</TT> command</B>: This is the command or path to GDB. We recommend version 13
+      or later. We require version 8 or later.</LI>
+
+      <LI><B>Run command</B>: This is the GDB command to actually launch the target. In most cases
+      this should be "<TT>starti,</TT>" since this will assure you an initial break and a chance to
+      enable your breakpoints.</LI>
+
+      <LI><B>Inferior TTY</B>: Depending on your target and/or personal preference, you may opt to
+      separate the debugger's and the target's I/O. If you check this box, the launcher will use
+      GDB's "<TT>set inferior-tty ...</TT>" command to direct the target's I/O to a second Terminal
+      window.</LI>
+    </UL>
+
+    <P>Once running, you are presented with GDB's command-line interface in Ghidra's Terminal. This
+    is the <EM>bona fide</EM> GDB command-line interface, so it has all the functionality you would
+    expect. If you command GDB from this shell, the plugin will keep Ghidra in sync. The terminal
+    can also be used to interact with the target application when it is running. The plugin
+    provides an additional set of commands for managing the connection to Ghidra, as well as
+    controlling trace synchronization. These are all in the "<TT>ghidra</TT>" command prefix. You
+    can use tab completion to enumerate the available commands and GDB's "<TT>help</TT>" command to
+    examine their documentation.</P>
+
+    <H2><A name="ssh"></A>Via SSH</H2>
+
+    <P>This works the same as the GDB launcher, but runs <TT>gdb</TT> on a remote system via
+    <TT>ssh</TT>. In contrast to the previous system, which used an SSH library for Java, this
+    launcher uses the <TT>ssh</TT> command on the local system. Thus, it should have broader
+    compatibility with remote systems, and it should use the same configuration files as you are
+    accustomed to. That said, we developed it using OpenSSH, so your experience will be best if
+    your copy understands the same command-line arguments.</P>
+
+    <H3>Setup</H3>
+
+    <P>You must install GDB and an SSH server onto the target host. Your local SSH client must
+    support remote port forwarding (-R option) and terminal allocation (<TT>-t</TT> option), and
+    the remote server must be configured to permit them.</P>
+
+    <P>You will need to manually install the required Python packages on the <EM>target</EM> host,
+    comprising our plugin for GDB and its dependencies. Copy all of the Python packages from
+    <TT>Ghidra/Debug/Debugger-rmi-trace/pypkg/dist/</TT> and
+    <TT>Ghidra/Debug/Debugger-agent-gdb/pypkg/dist/</TT> to the remote system. It is easiest to put
+    them all in one directory, e.g., <TT>~/ghidra-pypgk/</TT>. Then install them:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+python3 -m pip install --no-index -f ~/ghidra-pypkg/ ghidragdb
+</PRE>
+      </LI>
+    </UL>
+
+    <P>Please see <A href="#setup">Setup</A> for notes about embedded Python interpreter
+    versions.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Image</B>: This is the path to the target binary image (ELF) <EM>on the remote
+      system</EM>. Ghidra will try to fill this in based on information gathered when the current
+      program was imported; however, it cannot examine the <EM>remote</EM> system. If the file
+      exists and is executable on the <EM>local</EM> machine, it will be filled in automatically.
+      Whether or not it is filled automatically, please ensure the location is correct with respect
+      to the remote system. <B>NOTE:</B> If you have patched the current program database, these
+      changes are <EM>not</EM> applied to the target. You can either 1) apply the same patches to
+      the target once it is running, or 2) export a patched copy of your image, copy it to the
+      target system, and direct this launcher to run it.</LI>
+
+      <LI><B>Arguments</B>: This works the same as in GDB.</LI>
+
+      <LI><B>[User@]Host</B>: This is the host name of the target system, optionally including a
+      user name. This is passed as is to <TT>ssh</TT>, which may interpret it according to local
+      configuration.</LI>
+
+      <LI><B>Remote Trace RMI Port</B>: An available TCP port on the target system, which will
+      listen for GDB's Trace RMI connection and forward it back to Ghidra.</LI>
+
+      <LI><B>Extra <TT>ssh</TT> arguments</B>: These are extra arguments to pass to <TT>ssh</TT>.
+      They are inserted immediately after the <TT>ssh</TT> command but before the host name. Beware
+      that syntax errors may cause strange behavior, and that not all features may be compatible
+      with this launcher.</LI>
+
+      <LI><B><TT>gdb</TT> command</B>: This works the same as in GDB, but with respect to the
+      <EM>remote</EM> file system.</LI>
+
+      <LI><B>Run command</B>: This works the same as in GDB.</LI>
+
+      <LI>Note there is no option to create a second Terminal (TTY) for the target.</LI>
+    </UL>
+
+    <H2><A name="gdbserver_ssh"></A><TT>gdbserver</TT> via SSH</H2>
+
+    <P>This works similarly to the GDB via SSH launcher, but instead of tunneling the Trace RMI
+    connection, tunnels the RSP (<TT>gdbserver</TT>) connection. There is actually a fairly elegant
+    method of doing this straight from within <TT>gdb</TT>, which is exactly what this launcher
+    does:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+target remote | ssh user@host gdbserver - /path/to/image
+</PRE>
+      </LI>
+    </UL>
+
+    <P>This has some advantages compared to running <TT>gdb</TT> on the remote target:</P>
+
+    <OL>
+      <LI>GDB may not be available on the remote target.</LI>
+
+      <LI>There is no need to install our plugin for GDB on the target.</LI>
+    </OL>
+
+    <P>But, it also has some drawbacks:</P>
+
+    <OL>
+      <LI><TT>gdbserver</TT> must be installed on the remote system, and the local <TT>gdb</TT>
+      must be compatible with it.</LI>
+
+      <LI>It may be slightly more annoying to map modules from the remote system, because of the
+      way GDB reports these modules.</LI>
+
+      <LI>The memory map may be absent. Though this is overcome by creating an entry for the entire
+      address space, if the map is of interest to your analysis, it may not be available.</LI>
+    </OL>
+
+    <H3>Setup</H3>
+
+    <P>You must have GDB installed on the local system and a compatible version of
+    <TT>gdbserver</TT> installed on the target system. You must have an SSH server installed on the
+    target system. It may be worth testing your setup manually (outside of Ghidra) to ensure
+    everything is configured correctly. On the local system, follow the steps given in <A href=
+    "#setup">Setup</A>. There are no additional Python requirements on the target system.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Image</B>: This works the same as in GDB via SSH.</LI>
+
+      <LI><B>Arguments</B>: This works the same as in GDB.</LI>
+
+      <LI><B>[User@]Host</B>: This works the same as in GDB via SSH.</LI>
+
+      <LI><B>Remote Trace RMI Port</B>: An available TCP port on the target system, which will
+      listen for GDB's Trace RMI connection and forward it back to Ghidra.</LI>
+
+      <LI><B>Extra <TT>ssh</TT> arguments</B>: This works the same as in GDB via SSH.</LI>
+
+      <LI><B><TT>gdbserver</TT> command</B>: This is the command or path to <TT>gdbserver</TT> with
+      respect to the <EM>remote</EM> file system.</LI>
+
+      <LI><B>Extra <TT>gdbserver</TT> arguments</B>: These are extra arguments to pass to
+      <TT>gdbserver</TT>. They are inserted immediately after <TT>gdbserver</TT> but before the
+      dash. Beware that syntax errors may cause strange behavior, and that not all features may be
+      compatible with this launcher.</LI>
+
+      <LI><B><TT>gdb</TT> command</B>: This works the same as in GDB, with respect to the
+      <EM>local</EM> file system.</LI>
+
+      <LI>Note there is no option to create a second Terminal (TTY) for the target.</LI>
+    </UL>
+
+    <H2><A name="qemu"></A>QEMU</H2>
+
+    <P>These launchers orchestrate a QEMU user- or system-mode target and connect to it using our
+    Python plugin for GDB. Ghidra will inspect the current program and attempt to map its language
+    to the appropriate QEMU command, but due to subtle errors and/or outright failure, the default
+    value for the <B>QEMU command</B> option often requires careful inspection.</P>
+
+    <P>There are two separate scripts for QEMU, one for user mode and one for system mode. Note
+    that QEMU does not support user-mode emulation on Windows, so that script is not available on
+    Windows hosts.</P>
+
+    <H3>Setup</H3>
+
+    <P>You must acquire versions of QEMU and GDB that support the target architecture. Aside from
+    the copy of QEMU required, setup is the same whether for user or system mode. As for GDB, on
+    many distributions of Linux, you can install <TT>gdb-multiarch</TT>. Follow the steps given in
+    <A href="#setup">Setup</A>.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Image</B>: This is the path to the target binary image (ELF). This works the same as
+      in GDB, but is passed to QEMU. This will also provide the name to GDB using its "<TT>file
+      ...</TT>" command.</LI>
+
+      <LI><B>Arguments</B> (User-mode only): These are the command-line arguments to pass into the
+      target process. These are passed as is on QEMU's command line.</LI>
+
+      <LI><B>QEMU command</B>: The command or path to QEMU.</LI>
+
+      <LI><B>QEMU Port</B>: An available TCP port for QEMU to listen on for GDB.</LI>
+
+      <LI><B>Extra <TT>qemu</TT> arguments</B>: Extra arguments to pass to <TT>qemu</TT> or
+      <TT>qemu-system</TT>. These are inserted immediately after the <TT>qemu</TT> command but
+      before the target image. Run <TT>qemu<EM>[-system]-arch</EM> --help</TT> to see the options
+      supported. Beware that syntax errors may cause strange behavior, and that not all QEMU
+      features may be compatible with Ghidra.</LI>
+
+      <LI><B><TT>gdb</TT> command</B>: This works the same as in GDB, but defaults to
+      "gdb-multiarch."</LI>
+
+      <LI><B>QEMU TTY</B>: This works similarly as in GDB, but just runs QEMU in the second
+      Terminal window.</LI>
+
+      <LI><B>Pull all section mappings</B>: For some targets the memory mappings cannot be
+      correctly conveyed to Ghidra module by module. This setting forces GDB to send the
+      <EM>section</EM> mappings to Ghidra. <B>Warning</B>: This operation is expensive for large
+      targets, so it should only be enabled if required (e.g. unable to correctly place
+      breakpoints). <A href=
+      "help/topics/DebuggerModulesPlugin/DebuggerModulesPlugin.html#auto_map">Auto-Map</A> by
+      Section is required when this option is enabled, or else address translation may
+      <EM>still</EM> be incorrect.</LI>
+    </UL>
+
+    <H2><A name="wine"></A>Wine</H2>
+
+    <P>This launchers runs <TT>wine</TT> in a <TT>gdb</TT> session on Linux and directs it to a
+    target Windows executable. There are other ways to rig a Windows target in GDB on Linux, but
+    this is the method we have chosen. This may prevent GDB from processing the object file,
+    because it is a PE file, and most copies of GDB for UNIX will support only ELF. Nevertheless,
+    Ghidra should recognize the target and map it, giving you symbols and debug info in the front
+    end, even if not in the GDB CLI.</P>
+
+    <H3>Setup</H3>
+
+    <P>In addition to the steps given in <A href="#setup">Setup</A>, you must install Wine on your
+    system. Prepare for configuration by locating the actual <TT>wine</TT> executable. These are
+    often in some library directory and named "<TT>wine32</TT>" or "<TT>wine64</TT>." To find them,
+    either examine the file list of the installed package, or dissect the wrapper <TT>wine</TT>
+    script, usually on your path:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+less $(which wine)
+</PRE>
+      </LI>
+    </UL>
+
+    <P>The locations are usually given in variables at the top of the script, e.g.,
+    "<TT>/usr/lib/wine/wine64</TT>". One is for 64-bit Windows targets and another is for 32-bit
+    Windows targets. Unlike native Windows, Wine does not (yet) implement WoW64 (Windows on Windows
+    64). Instead, the 32-bit target is loaded using a 32-bit copy of Wine, and so is serviced by
+    Linux's 32-bit system calls. <FONT color="red"><B>NOTE:</B> Careful attention must be given to
+    select the correct <TT>wine</TT> executable for the target program's architecture!</FONT> Even
+    though the <TT>wine</TT> executable is smart enough to correct this mistake, it results in
+    calls to <TT>exec</TT>, which confuse this launcher. If GDB complains that it cannot place
+    breakpoints because of memory access, it is probably because of this mistake.</P>
+
+    <P>The launcher loads some additional support packages in our plugin for GDB, e.g., to scan the
+    memory map for PE files and amend the module list. Thus, Ghidra can display both Windows and
+    Linux modules, and map them to its program databases accordingly, despite GDB's inability to
+    process PE files. There are perhaps other configurations of GDB for Linux that can process ELFs
+    as well as PEs loaded by Wine, but they do not seem to be readily available in any popular
+    package repositories.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Image</B>: This is the path to the target binary image (EXE). This works the same as
+      in GDB, but is passed to Wine via GDB's "<TT>set args ...</TT>". This will also provide the
+      name to GDB using its "<TT>file ...</TT>" command.</LI>
+
+      <LI><B>Arguments</B>: These are the command-line arguments to pass into the target process.
+      These are included in "<TT>set args ...</TT>".</LI>
+
+      <LI><B>Path to <TT>wine</TT> binary</B>: The path to wine for your target architecture. <FONT
+      color="red">See note above!</FONT></LI>
+
+      <LI><B><TT>gdb</TT> command</B>: This works the same as in GDB.</LI>
+
+      <LI><B>Inferior TTY</B>: This works the same as in GDB.</LI>
+    </UL>
+
+    <H2><A name="remote"></A>Remote</H2>
+
+    <P>This launcher can target any TCP-based GDB stub that is compatible with a local copy of
+    <TT>gdb</TT>. Essentially, it just starts <TT>gdb</TT> and then enters</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+target remote [host]:[port]
+</PRE>
+      </LI>
+    </UL>
+
+    <P>into it. It is best to test this command outside of Ghidra to be sure everything is
+    compatible before using this launcher. This launcher does not require an image, nor does it
+    create your target. Thus, it can be used without a current program.</P>
+
+    <H3>Setup</H3>
+
+    <P>On your local system, follow the steps given in <A href="#setup">Setup</A>. Your version of
+    GDB must be compatible with the stub (e.g., <TT>gdbserver</TT>) on the target system. There are
+    no additional requirements on the target system.</P>
+
+    <P><B>NOTE:</B> The target program image must match that imported in Ghidra, or else things may
+    not map or synchronize correctly.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Target</B>: The type of target. Either <TT>remote</TT> or <TT>remote-extended</TT>,
+      depending on the capabilities of the stub.</LI>
+
+      <LI><B>Host</B>: The host name of the target stub.</LI>
+
+      <LI><B>Port</B>: The TCP port of the target stub.</LI>
+
+      <LI><B>Architecture</B> (optional): If the stub does not describe its architecture to GDB,
+      you must set it before connecting. This is passed as is to "<TT>set arch ...</TT>"
+      immediately before the "<TT>target ...</TT>" command. Enter "<TT>set arch</TT>" into a GDB
+      session outside of Ghidra to see the list of available options in your configuration. You may
+      want to use <TT>gdb-multiarch</TT>.</LI>
+
+      <LI><B><TT>gdb</TT> command</B>: This works the same as in GDB, though you may want to use
+      <TT>gdb-multiarch</TT>.</LI>
+    </UL>
+
+    <H2><A name="rr"></A>rr</H2>
+
+    <P>This launcher runs <TT>rr</TT> in a <TT>gdb</TT> session on Linux for replaying rr-generated
+    traces.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Trace Dir</B>: This is the path to the trace directory, stored by default in the
+      user's home directory in <TT>.local/share/rr/target_name</TT>.</LI>
+
+      <LI><B><TT>rr</TT> command</B>: This is the command or path to <TT>rr</TT>.</LI>
+    </UL>
+
+    <P>Other options are the same as in GDB.</P>
+  </BODY>
+</HTML>

Ghidra/Debug/Debugger-agent-lldb/build.gradle

@@ -13,8 +13,17 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
+// Not technically a Java project, but required to be a Help project
+apply from: "${rootProject.projectDir}/gradle/javaProject.gradle"
+apply from: "${rootProject.projectDir}/gradle/helpProject.gradle"
 apply from: "$rootProject.projectDir/gradle/distributableGhidraModule.gradle"
 apply from: "$rootProject.projectDir/gradle/hasPythonPackage.gradle"
 
 apply plugin: 'eclipse'
 eclipse.project.name = 'Debug Debugger-agent-lldb'
+
+dependencies {
+	// Only for Help :/
+	api project(':Debugger-rmi-trace')
+	api project(':Debugger-agent-gdb')
+}

Ghidra/Debug/Debugger-agent-lldb/certification.manifest

@@ -9,6 +9,8 @@ data/debugger-launchers/kernel-lldb.bat||GHIDRA||||END|
 data/debugger-launchers/local-lldb.bat||GHIDRA||||END|
 data/debugger-launchers/remote-lldb.bat||GHIDRA||||END|
 data/debugger-launchers/ssh-lldb.bat||GHIDRA||||END|
+src/main/help/help/TOC_Source.xml||GHIDRA||||END|
+src/main/help/help/topics/lldb/lldb.html||GHIDRA||||END|
 src/main/py/LICENSE||GHIDRA||||END|
 src/main/py/MANIFEST.in||GHIDRA||||END|
 src/main/py/README.md||GHIDRA||||END|

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/android-lldb.bat

@@ -8,7 +8,7 @@
 ::@desc </body></html>
 ::@menu-group remote
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#lldb_android
+::@help lldb#android
 ::@enum StartCmd:str "process launch" "process launch --stop-at-entry"
 ::@env OPT_TARGET_IMG:file="" "Image" "The target binary executable image"
 ::@env OPT_TARGET_ARGS:str="" "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/android-lldb.sh

@@ -25,7 +25,7 @@
 #@desc </body></html>
 #@menu-group remote
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#lldb_android
+#@help lldb#android
 #@enum StartCmd:str "process launch" "process launch --stop-at-entry"
 #@arg :file "Image" "The target binary executable image"
 #@args "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/kernel-lldb.bat

@@ -8,7 +8,7 @@
 ::@desc </body></html>
 ::@menu-group remote
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#lldb_kernel
+::@help lldb#macos_kernel
 ::@env OPT_HOST:str="localhost" "Host" "The hostname of the target"
 ::@env OPT_ARCH:str="" "Architecture" "Target architecture override"
 ::@env OPT_LLDB_PATH:file="lldb" "lldb command" "The path to lldb on the local system. Omit the full path to resolve using the system PATH."

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/kernel-lldb.sh

@@ -24,7 +24,7 @@
 #@desc </body></html>
 #@menu-group remote
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#lldb_kernel
+#@help lldb#macos_kernel
 #@env OPT_HOST:str="localhost" "Host" "The hostname of the target"
 #@env OPT_ARCH:str="" "Architecture" "Target architecture override"
 #@env OPT_LLDB_PATH:file="lldb" "lldb command" "The path to lldb on the local system. Omit the full path to resolve using the system PATH."

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/local-lldb.bat

@@ -9,7 +9,7 @@
 ::@desc </body></html>
 ::@menu-group local
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#lldb
+::@help lldb#local
 ::@enum StartCmd:str "process launch" "process launch --stop-at-entry"
 ::@env OPT_TARGET_IMG:file="" "Image" "The target binary executable image"
 ::@env OPT_TARGET_ARGS:str="" "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/local-lldb.sh

@@ -25,7 +25,7 @@
 #@desc </body></html>
 #@menu-group local
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#lldb
+#@help lldb#local
 #@enum StartCmd:str "process launch" "process launch --stop-at-entry"
 #@arg :file "Image" "The target binary executable image"
 #@args "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/remote-lldb.bat

@@ -8,7 +8,7 @@
 ::@desc </body></html>
 ::@menu-group remote
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#lldb_remote
+::@help lldb#remote
 ::@env OPT_HOST:str="localhost" "Host" "The hostname of the target"
 ::@env OPT_PORT:str="9999" "Port" "The host's listening port"
 ::@env OPT_ARCH:str="" "Architecture" "Target architecture override"

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/remote-lldb.sh

@@ -24,7 +24,7 @@
 #@desc </body></html>
 #@menu-group remote
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#lldb_remote
+#@help lldb#remote
 #@env OPT_HOST:str="localhost" "Host" "The hostname of the target"
 #@env OPT_PORT:str="9999" "Port" "The host's listening port"
 #@env OPT_ARCH:str="" "Architecture" "Target architecture override"

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/ssh-lldb.bat

@@ -10,7 +10,7 @@
 ::@desc </body></html>
 ::@menu-group remote
 ::@icon icon.debugger
-::@help TraceRmiLauncherServicePlugin#lldb_ssh
+::@help lldb#ssh
 ::@enum StartCmd:str "process launch" "process launch --stop-at-entry"
 ::@enum Endian:str auto big little
 ::@env OPT_TARGET_IMG:str="" "Image" "The target binary executable image on the remote system"

Ghidra/Debug/Debugger-agent-lldb/data/debugger-launchers/ssh-lldb.sh

@@ -26,7 +26,7 @@
 #@desc </body></html>
 #@menu-group remote
 #@icon icon.debugger
-#@help TraceRmiLauncherServicePlugin#lldb_ssh
+#@help lldb#ssh
 #@enum StartCmd:str "process launch" "process launch --stop-at-entry"
 #@enum Endian:str auto big little
 #@arg :str "Image" "The target binary executable image on the remote system"

Ghidra/Debug/Debugger-agent-lldb/src/main/help/help/TOC_Source.xml

@@ -0,0 +1,25 @@
+<?xml version='1.0' encoding='ISO-8859-1'?>
+<!-- See Base's TOC_Source.xml for help -->
+<tocroot>
+	<tocref id="TraceRmiLauncherServicePlugin">
+		<tocdef id="lldb" text="LLDB Integration"
+			target="help/topics/lldb/lldb.html">
+
+			<tocdef id="lldb_local" text="Local"
+				target="help/topics/lldb/lldb.html#local" />
+
+			<tocdef id="lldb_remote" text="Remote"
+				target="help/topics/lldb/lldb.html#remote" />
+
+			<tocdef id="lldb_macos_kenel" text="macOS Kernel"
+				target="help/topics/lldb/lldb.html#macos_kernel" />
+
+			<tocdef id="lldb_ssh" text="Via SSH"
+				target="help/topics/lldb/lldb.html#ssh" />
+
+			<tocdef id="lldb_android" text="Android (native)"
+				target="help/topics/lldb/lldb.html#android" />
+
+		</tocdef>
+	</tocref>
+</tocroot>

Ghidra/Debug/Debugger-agent-lldb/src/main/help/help/topics/lldb/lldb.html

@@ -0,0 +1,209 @@
+<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
+
+<HTML>
+  <HEAD>
+    <META name="generator" content=
+    "HTML Tidy for Java (vers. 2009-12-01), see jtidy.sourceforge.net">
+
+    <TITLE>Debugger Launchers: LLDB</TITLE>
+    <META http-equiv="Content-Type" content="text/html; charset=windows-1252">
+    <LINK rel="stylesheet" type="text/css" href="help/shared/DefaultStyle.css">
+  </HEAD>
+
+  <BODY lang="EN-US">
+    <H1>Debugger Launchers: LLDB</H1>
+
+    <P>Integration with LLDB is achieved using a plugin for LLDB's Python Scripting Bridge. It is
+    well-suited for debuging user-space targets on a variety of platforms. It is the <EM>de
+    facto</EM> debugger for macOS. It can be obtained by installing Xcode from the App Store.
+    Though it may require a bit more careful configuration, it can also be obtained from other
+    repositories like <TT>brew</TT>.</P>
+
+    <P>The following launchers based on the LLDB Debugger are included out of the box:</P>
+
+    <H2><A name="local"></A>Local</H2>
+
+    <P>The plain "<TT>lldb</TT>" launch script defaults to launching the current program as a
+    user-mode process on the local system. If there is no current program, or if you clear the
+    <B>Image</B> option, this launcher will only start <TT>lldb</TT> and get it connected to a
+    Ghidra trace. You may then manually start or connect to your target. Note that this may also
+    require manual mapping of your program database(s) to the target memory.</P>
+
+    <H3><A name="setup"></A>Setup</H3>
+
+    <P>You must have LLDB installed on the local system, and it must support Python 3 scripting. If
+    you have access to PyPI, setting up your Python 3 environment is done using Pip. Please note
+    the version specifier for Protobuf.</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+python3 -m pip install psutil protobuf==3.20.3
+</PRE>
+      </LI>
+    </UL>
+
+    <P>If you are offline, or would like to use our provided packages, we still use Pip, but with a
+    more complicated invocation:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+cd /path/to/ghidra_<EM>
+version</EM>/Ghidra/Debug
+python3 -m pip install --no-index -f Debugger-rmi-trace/pypkg/dist -f Debugger-agent-lldb/pypkg/dist psutil protobuf
+</PRE>
+      </LI>
+    </UL>
+
+    <P>Beware that LLDB may embed a different Python interpreter than your system's default. If you
+    are still getting import errors, check the version that LLDB embeds:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+(bash)$ lldb
+(lldb) script
+&gt;&gt;&gt; import sys
+&gt;&gt;&gt; sys.version
+</PRE>
+      </LI>
+    </UL>
+
+    <P>Note the version and ensure that you are invoking Pip with that version. Supposing
+    <TT>sys.version</TT> indicates 3.10, you should invoke Pip using <TT>python3.10 -m
+    pip</TT>.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Image</B>: This is the path to the target binary image (executable). Ghidra will try
+      to fill this in based on information gathered when the current program was imported. If the
+      file exists and is executable on the local machine, it will be filled in automatically.
+      Otherwise, it is up to you to locate it. <B>NOTE:</B> If you have patched the current program
+      database, these changes are <EM>not</EM> applied to the target. You can either 1) apply the
+      same patches to the target once it is running, or 2) export a patched copy of your image and
+      direct this launcher to run it.</LI>
+
+      <LI><B>Arguments</B>: These are the command-line arguments to pass into the target. These are
+      passed as is to LLDB's "<TT>settings set target.run-args ...</TT>" command.</LI>
+
+      <LI><B><TT>lldb</TT> command</B>: This is the command or path to LLDB. We recommend version
+      15 or later.</LI>
+
+      <LI><B>Run command</B>: This is the LLDB command to actually launch the target. In most cases
+      this should include "<TT>--stop-at-entry</TT>", since this will assure you an initial break
+      and a chance to enable your breakpoints.</LI>
+
+      <LI><B>Target TTY</B>: Depending on your target and/or personal preference, you may opt to
+      separate the debugger's and the target's I/O. If you check this box, the launcher will use
+      LLDB's "<TT>setting set target.output-path ...</TT>" command (and similar for the input) to
+      direct the target's I/O to a second Terminal window.</LI>
+    </UL>
+
+    <P>Once running, you are presented with LLDB's command-line interface in Ghidra's Terminal.
+    This is the <EM>bona fide</EM> LLDB command-line interface, so it has all the functionality you
+    would expect. If you command LLDB from this shell, the plugin will keep Ghidra in sync. The
+    terminal can be used to interact with the target application when it is running. The plugin
+    provides an additional set of commands for managing the connection to Ghidra, as well as
+    controlling trace synchronization. These are all in the "<TT>ghidra</TT>" category. You can use
+    tab completion to enumerate the available commands and LLDB's "<TT>help</TT>" command to
+    examine their documentation.</P>
+
+    <H2><A name="remote"></A>Remote</H2>
+
+    <P>This launcher can target any TCP-based GDB stub that is compatible with a local copy of
+    <TT>lldb</TT>. Essentially, it just starts <TT>lldb</TT> and then enters</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+gdb-remote [host]:[port]
+</PRE>
+      </LI>
+    </UL>
+
+    <P>into it. It is best to test this command outside of Ghidra to be sure everything is
+    compatible before using this launcher. This launcher does not require an image, nor does it
+    create your target. Thus, it can be used without a current program.</P>
+
+    <H3>Setup</H3>
+
+    <P>On your local system, follow the steps given in <A href="#setup">LLDB Setup</A>. Your
+    version of LLDB must be compatible with the stub (e.g., <TT>gdbserver</TT>) on the target
+    system. There are no additional requirements on the target system.</P>
+
+    <P><B>NOTE:</B> The target program image must match that imported in Ghidra, or else things may
+    not map or synchronize correctly.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Host</B>: The host name of the target stub.</LI>
+
+      <LI><B>Port</B>: The TCP port of the target stub.</LI>
+
+      <LI><B>Architecture</B> (optional): If the stub does not describe its architecture to LLDB,
+      you must set it before connecting. This is passed as is to "<TT>settings set
+      target.default-arch ...</TT>" immediately before the "<TT>gdb-remote ...</TT>" command.</LI>
+
+      <LI><B><TT>lldb</TT> command</B>: This works the same as in LLDB.</LI>
+    </UL>
+
+    <H2><A name="macos_kernel"></A>macOS Kernel</H2>
+
+    <P>This launcher connects to macOS kernels booted in debug-mode using <TT>lldb</TT>.
+    Essentially, it just starts <TT>lldb</TT> and then enters</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+kdp-remote [host]
+</PRE>
+      </LI>
+    </UL>
+
+    <P>It is best to test this command outside of Ghidra to be sure everything is compatible before
+    using this launcher. This launcher does not require an image, nor does it create your target.
+    Thus, it can be used without a current program.</P>
+
+    <H3>Setup</H3>
+
+    <P>On your local system, follow the steps given in <A href="#setup">LLDB Setup</A>. Before
+    connecting to the target kernel, you must force an NMI on the target to ready the connection.
+    On actual hardware, this is typically achieved by some button sequence, e.g. <B>L/R-Options +
+    Power</B> or <B>Command+Option+Control+Shift+Esc</B>. In a VM, you may have to pause the VM and
+    modify its state. For example, by cd'ing to the VM's container and issuing the command:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+perl -i -pe 's/(?&lt;=pendingNMI\x00{4})\x00/\x01/' macOS_15-1234567.vmss
+</PRE>
+      </LI>
+    </UL>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Host</B>: The host IP of the target kernel.</LI>
+
+      <LI><B>Architecture</B> (optional): If the kernel does not describe its architecture to LLDB,
+      you must set it before connecting. This is passed as is to "<TT>settings set
+      target.default-arch ...</TT>" immediately before the "<TT>kdp-remote ...</TT>" command.</LI>
+
+      <LI><B><TT>lldb</TT> command</B>: This works the same as in LLDB.</LI>
+    </UL>
+
+    <H2><A name="ssh"></A>Via SSH</H2>
+
+    <P>This works the same as the <A href="help/topics/gdb/gdb.html#ssh">GDB via SSH</A> launcher,
+    but runs <TT>lldb</TT> on a remote system via <TT>ssh</TT>.</P>
+
+    <H2><A name="android"></A>Android</H2>
+
+    <P>This has the same options as the <A href="#ssh">LLDB via SSH</A> launcher, which are
+    necessary for connecting to the Android debugger, but executes via the normal lldb
+    mechanism.</P>
+  </BODY>
+</HTML>

Ghidra/Debug/Debugger-jpda/build.gradle

@@ -14,6 +14,7 @@
  * limitations under the License.
  */
 apply from: "${rootProject.projectDir}/gradle/javaProject.gradle"
+apply from: "${rootProject.projectDir}/gradle/helpProject.gradle"
 apply from: "${rootProject.projectDir}/gradle/jacocoProject.gradle"
 apply from: "${rootProject.projectDir}/gradle/javaTestProject.gradle"
 apply from: "${rootProject.projectDir}/gradle/distributableGhidraModule.gradle"

Ghidra/Debug/Debugger-jpda/certification.manifest

@@ -4,4 +4,6 @@ README.md||GHIDRA||||END|
 data/debugger-launchers/attach-java.jsh||GHIDRA||||END|
 data/debugger-launchers/bypid-java.jsh||GHIDRA||||END|
 data/debugger-launchers/local-java.jsh||GHIDRA||||END|
+src/main/help/help/TOC_Source.xml||GHIDRA||||END|
+src/main/help/help/topics/jpda/jpda.html||GHIDRA||||END|
 src/main/resources/ghidra/app/plugin/core/debug/client/tracermi/jdi_schema.xml||GHIDRA||||END|

Ghidra/Debug/Debugger-jpda/data/debugger-launchers/attach-java.jsh

@@ -9,7 +9,7 @@
 //@desc </body></html>
 //@menu-group attach
 //@icon icon.debugger
-//@help TraceRmiLauncherServicePlugin#java_attach
+//@help jpda#attach_port
 //@enum Arch:str JVM Dalvik
 //@env OPT_ARCH:Arch="JVM" "Arch" "Target architecture"
 //@env OPT_HOST:str="localhost" "Host" "The hostname of the target"

Ghidra/Debug/Debugger-jpda/data/debugger-launchers/bypid-java.jsh

@@ -9,7 +9,7 @@
 //@desc </body></html>
 //@menu-group attach
 //@icon icon.debugger
-//@help TraceRmiLauncherServicePlugin#java_bypid
+//@help jpda#attach_pid
 //@enum Arch:str JVM Dalvik
 //@env OPT_ARCH:Arch="JVM" "Arch" "Target architecture"
 //@env OPT_PID:str="" "Pid" "The target process id"

Ghidra/Debug/Debugger-jpda/data/debugger-launchers/local-java.jsh

@@ -10,7 +10,7 @@
 //@desc </body></html>
 //@menu-group local
 //@icon icon.debugger
-//@help TraceRmiLauncherServicePlugin#java
+//@help jpda#local
 //@env OPT_TARGET_CLASS:file="" "Image" "The Main Class to launch (defaults to current program)."
 //@env OPT_TARGET_CLASSPATH:str="" "ClassPath" "The JVM classpath"
 //@args "Arguments" "Command-line arguments to pass to the target"

Ghidra/Debug/Debugger-jpda/src/main/help/help/TOC_Source.xml

@@ -0,0 +1,19 @@
+<?xml version='1.0' encoding='ISO-8859-1'?>
+<!-- See Base's TOC_Source.xml for help -->
+<tocroot>
+	<tocref id="TraceRmiLauncherServicePlugin">
+		<tocdef id="jpda" text="Java Debugger Integration"
+			target="help/topics/jpda/jpda.html">
+
+			<tocdef id="jpda_local" text="Local"
+				target="help/topics/jpda/jpda.html#local" />
+
+			<tocdef id="jpda_attach_port" text="Attach by JDWP"
+				target="help/topics/jpda/jpda.html#attach_port" />
+
+			<tocdef id="jpda_attach_pid" text="Attach b PID"
+				target="help/topics/jpda/jpda.html#attach_pid" />
+
+		</tocdef>
+	</tocref>
+</tocroot>

Ghidra/Debug/Debugger-jpda/src/main/help/help/topics/jpda/jpda.html

@@ -0,0 +1,100 @@
+<!DOCTYPE doctype PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">
+
+<HTML>
+  <HEAD>
+    <META name="generator" content=
+    "HTML Tidy for Java (vers. 2009-12-01), see jtidy.sourceforge.net">
+
+    <TITLE>Debugger Launchers: Java</TITLE>
+    <META http-equiv="Content-Type" content="text/html; charset=windows-1252">
+    <LINK rel="stylesheet" type="text/css" href="help/shared/DefaultStyle.css">
+  </HEAD>
+
+  <BODY lang="EN-US">
+    <H1>Debugger Launchers: Java</H1>
+
+    <P>Our Java Debugger is implemented using the JDK's built-in JPDA/JDI API. We currently have a
+    mode which embeds it in a <TT>jshell</TT> for CLI-based diagnostics. It is well-suited for Java
+    and Dalvik (Android VM) targets.</P>
+
+    <P>The following launchers based on the Java Debugger are included out of the box:</P>
+
+    <H2><A name="local"></A>Local</H2>
+
+    <P>The plain "<TT>java</TT>" launcher uses the native Java Debug Interface (JDI) to launch the
+    current <TT>.class</TT> file locally.</P>
+
+    <H3>Setup</H3>
+
+    <P>You must have Java installed on the local system. No additional setup is required.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Arguments</B>: These are the command-line arguments to pass into the target.</LI>
+
+      <LI><B>Arch</B>: The architecture (currently, either "JVM" or "Dalvik").</LI>
+
+      <LI><B>Suspend</B>: Should the target be suspended on launch.</LI>
+
+      <LI><B>Include virtual threads</B>: As described.</LI>
+
+      <LI><B>JShell cmd</B>: If desired, the path to the jshell binary that will host
+      execution.</LI>
+    </UL>
+
+    <H2><A name="attach_port"></A>Attach by JDWP</H2>
+
+    <P>This launcher uses the native Java Debug Interface (JDI) to attach to a running java program
+    launched with an open Java Debug Wire Port (JDWP) over TCP, e.g.:</P>
+
+    <UL style="list-style-type: none">
+      <LI>
+<PRE>
+java -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:54321 Target.class
+</PRE>
+      </LI>
+    </UL>
+
+    <H3>Setup</H3>
+
+    <P>Identical to that for the java launcher.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Arch</B>: The architecture (currently, either "JVM" or "Dalvik").</LI>
+
+      <LI><B>Host</B>: The host IP where the target is running.</LI>
+
+      <LI><B>Port</B>: The open JDWP port used by the target.</LI>
+
+      <LI><B>Timeout</B>: How long to wait for a connection attempt.</LI>
+
+      <LI><B>JShell cmd</B>: If desired, the path to the jshell binary that will host
+      execution.</LI>
+    </UL>
+
+    <H2><A name="attach_pid"></A>Attach by PID</H2>
+
+    <P>This launcher uses the native Java Debug Interface (JDI) to attach to a running java program
+    launched with a Java Debug Wire Port (JDWP) identified by process id.</P>
+
+    <H3>Setup</H3>
+
+    <P>Identical to that for the java launcher.</P>
+
+    <H3>Options</H3>
+
+    <UL>
+      <LI><B>Arch</B>: The architecture (currently, either "JVM" or "Dalvik").</LI>
+
+      <LI><B>Pid</B>: The target process's ID.</LI>
+
+      <LI><B>Timeout</B>: How long to wait for a connection attempt.</LI>
+
+      <LI><B>JShell cmd</B>: If desired, the path to the jshell binary that will host
+      execution.</LI>
+    </UL>
+  </BODY>
+</HTML>

Ghidra/Debug/Debugger-rmi-trace/certification.manifest

@@ -10,7 +10,6 @@ src/main/help/help/topics/TraceRmiConnectionManagerPlugin/TraceRmiConnectionMana
 src/main/help/help/topics/TraceRmiConnectionManagerPlugin/images/ConnectDialog.png||GHIDRA||||END|
 src/main/help/help/topics/TraceRmiConnectionManagerPlugin/images/TraceRmiConnectionManagerPlugin.png||GHIDRA||||END|
 src/main/help/help/topics/TraceRmiLauncherServicePlugin/TraceRmiLauncherServicePlugin.html||GHIDRA||||END|
-src/main/help/help/topics/TraceRmiLauncherServicePlugin/images/GdbLauncher.png||GHIDRA||||END|
 src/main/help/help/topics/TraceRmiLauncherServicePlugin/images/GdbTerminal.png||GHIDRA||||END|
 src/main/py/LICENSE||GHIDRA||||END|
 src/main/py/README.md||GHIDRA||||END|

Ghidra/Debug/Debugger-rmi-trace/src/main/help/help/TOC_Source.xml

@@ -1,61 +1,13 @@
-<?xml version='1.0' encoding='ISO-8859-1' ?>
+<?xml version='1.0' encoding='ISO-8859-1'?>
-<!-- 
+<!-- See Base's TOC_Source.xml for help -->
-
-	This is an XML file intended to be parsed by the Ghidra help system.  It is loosely based 
-	upon the JavaHelp table of contents document format.  The Ghidra help system uses a 
-	TOC_Source.xml file to allow a module with help to define how its contents appear in the 
-	Ghidra help viewer's table of contents.  The main document (in the Base module) 
-	defines a basic structure for the 
-	Ghidra table of contents system.  Other TOC_Source.xml files may use this structure to insert
-	their files directly into this structure (and optionally define a substructure).
-	
-	
-	In this document, a tag can be either a <tocdef> or a <tocref>.  The former is a definition
-	of an XML item that may have a link and may contain other <tocdef> and <tocref> children.  
-	<tocdef> items may be referred to in other documents by using a <tocref> tag with the 
-	appropriate id attribute value.  Using these two tags allows any module to define a place 
-	in the table of contents system (<tocdef>), which also provides a place for 
-	other TOC_Source.xml files to insert content (<tocref>).  
-	
-	During the help build time, all TOC_Source.xml files will be parsed and	validated to ensure
-	that all <tocref> tags point to valid <tocdef> tags.  From these files will be generated
-	<module name>_TOC.xml files, which are table of contents files written in the format 
-	desired by the JavaHelp system.   Additionally, the generated files will be merged together
-	as they are loaded by the JavaHelp system.  In the end, when displaying help in the Ghidra
-	help GUI, there will be one table of contents that has been created from the definitions in 
-	all of the modules' TOC_Source.xml files.
-
-	
-	Tags and Attributes
-	
-	<tocdef>
-	-id          - the name of the definition (this must be unique across all TOC_Source.xml files)	
-	-text        - the display text of the node, as seen in the help GUI
-	-target**    - the file to display when the node is clicked in the GUI
-	-sortgroup   - this is a string that defines where a given node should appear under a given
-	               parent.  The string values will be sorted by the JavaHelp system using
-	               a javax.text.RulesBasedCollator.  If this attribute is not specified, then
-	               the text of attribute will be used.
-
-	<tocref>
-	-id			 - The id of the <tocdef> that this reference points to 
-	
-	**The URL for the target is relative and should start with 'help/topics'.  This text is 
-	used by the Ghidra help system to provide a universal starting point for all links so that
-	they can be resolved at runtime, across modules.
-	
-	
--->
-
-
 <tocroot>
-		<tocref id="Debugger" >
+	<tocref id="Debugger">
 		<tocdef id="TraceRmiConnectionManagerPlugin" text="Connection Manager"
-			        sortgroup="m"
+			sortgroup="mm"
 			target="help/topics/TraceRmiConnectionManagerPlugin/TraceRmiConnectionManagerPlugin.html" />
 
 		<tocdef id="TraceRmiLauncherServicePlugin" text="Launchers"
-			        sortgroup="m"
+			sortgroup="ga"
 			target="help/topics/TraceRmiLauncherServicePlugin/TraceRmiLauncherServicePlugin.html" />
 	</tocref>
 </tocroot>

Ghidra/Debug/Debugger/src/main/help/help/TOC_Source.xml

@@ -1,61 +1,13 @@
-<?xml version='1.0' encoding='ISO-8859-1' ?>
+<?xml version='1.0' encoding='ISO-8859-1'?>
-<!-- 
+<!-- See Base's TOC_Source.xml for help -->
-
-	This is an XML file intended to be parsed by the Ghidra help system.  It is loosely based 
-	upon the JavaHelp table of contents document format.  The Ghidra help system uses a 
-	TOC_Source.xml file to allow a module with help to define how its contents appear in the 
-	Ghidra help viewer's table of contents.  The main document (in the Base module) 
-	defines a basic structure for the 
-	Ghidra table of contents system.  Other TOC_Source.xml files may use this structure to insert
-	their files directly into this structure (and optionally define a substructure).
-	
-	
-	In this document, a tag can be either a <tocdef> or a <tocref>.  The former is a definition
-	of an XML item that may have a link and may contain other <tocdef> and <tocref> children.  
-	<tocdef> items may be referred to in other documents by using a <tocref> tag with the 
-	appropriate id attribute value.  Using these two tags allows any module to define a place 
-	in the table of contents system (<tocdef>), which also provides a place for 
-	other TOC_Source.xml files to insert content (<tocref>).  
-	
-	During the help build time, all TOC_Source.xml files will be parsed and	validated to ensure
-	that all <tocref> tags point to valid <tocdef> tags.  From these files will be generated
-	<module name>_TOC.xml files, which are table of contents files written in the format 
-	desired by the JavaHelp system.   Additionally, the generated files will be merged together
-	as they are loaded by the JavaHelp system.  In the end, when displaying help in the Ghidra
-	help GUI, there will be one table of contents that has been created from the definitions in 
-	all of the modules' TOC_Source.xml files.
-
-	
-	Tags and Attributes
-	
-	<tocdef>
-	-id          - the name of the definition (this must be unique across all TOC_Source.xml files)	
-	-text        - the display text of the node, as seen in the help GUI
-	-target**    - the file to display when the node is clicked in the GUI
-	-sortgroup   - this is a string that defines where a given node should appear under a given
-	               parent.  The string values will be sorted by the JavaHelp system using
-	               a javax.text.RulesBasedCollator.  If this attribute is not specified, then
-	               the text of attribute will be used.
-
-	<tocref>
-	-id			 - The id of the <tocdef> that this reference points to 
-	
-	**The URL for the target is relative and should start with 'help/topics'.  This text is 
-	used by the Ghidra help system to provide a universal starting point for all links so that
-	they can be resolved at runtime, across modules.
-	
-	
--->
-
-
 <tocroot>
 	<tocref id="Ghidra Functionality">
 		<tocdef id="Debugger" text="Debugger"
-		        target="help/topics/Debugger/Debugger.html" >
+			target="help/topics/Debugger/Debugger.html">
 
 			<tocdef id="DebuggerGettingStarted" text="Getting Started"
 				sortgroup="g"
-			        target="help/topics/Debugger/GettingStarted.html" >
+				target="help/topics/Debugger/GettingStarted.html">
 
 				<tocdef id="Launching" text="Launching a Target"
 					sortgroup="a"
@@ -82,7 +34,8 @@
 				sortgroup="m"
 				target="help/topics/DebuggerThreadsPlugin/DebuggerThreadsPlugin.html" />
 
-			<tocdef id="DebuggerTraceManagerServicePlugin" text="Trace Management"
+			<tocdef id="DebuggerTraceManagerServicePlugin"
+				text="Trace Management"
 				sortgroup="m"
 				target="help/topics/DebuggerTraceManagerServicePlugin/DebuggerTraceManagerServicePlugin.html" />
 
@@ -102,7 +55,8 @@
 				sortgroup="m"
 				target="help/topics/DebuggerListingPlugin/DebuggerListingPlugin.html" />
 
-			<tocdef id="DebuggerDisassemblerPlugin" text="Disassembly and Assembly"
+			<tocdef id="DebuggerDisassemblerPlugin"
+				text="Disassembly and Assembly"
 				sortgroup="m"
 				target="help/topics/DebuggerDisassemblerPlugin/DebuggerDisassemblerPlugin.html" />
 
@@ -112,9 +66,10 @@
 
 			<tocdef id="DebuggerBreakpointsPlugin" text="Breakpoints"
 				sortgroup="m"
-			       target="help/topics/DebuggerBreakpointsPlugin/DebuggerBreakpointsPlugin.html" >
+				target="help/topics/DebuggerBreakpointsPlugin/DebuggerBreakpointsPlugin.html">
 
-				<tocdef id="DebuggerBreakpointMarkerPlugin" text="In the Listings"
+				<tocdef id="DebuggerBreakpointMarkerPlugin"
+					text="In the Listings"
 					sortgroup="a"
 					target="help/topics/DebuggerBreakpointMarkerPlugin/DebuggerBreakpointMarkerPlugin.html" />
 			</tocdef>
@@ -129,7 +84,7 @@
 
 			<tocdef id="DebuggerModulesPlugin" text="Modules and Sections"
 				sortgroup="m"
-			        target="help/topics/DebuggerModulesPlugin/DebuggerModulesPlugin.html" >
+				target="help/topics/DebuggerModulesPlugin/DebuggerModulesPlugin.html">
 
 				<tocdef id="DebuggerStaticMappingPlugin" text="Static Mappings"
 					sortgroup="a"

Ghidra/Debug/Debugger/src/main/help/help/topics/DebuggerDisassemblerPlugin/DebuggerDisassemblerPlugin.html

@@ -33,5 +33,9 @@
     configured at the current location. Other languages may also be presented if the only thing
     that varies is the default disassembly context, e.g., configuring ARM will also allow THUMB
     assembly.</P>
+
+    <H3><A name="patch_data"></A> Patch Data</H3>
+
+    <P>This action patches the data unit at the cursor, if its type provides an encoder.</P>
   </BODY>
 </HTML>

Ghidra/Test/DebuggerIntegrationTest/src/screen/java/ghidra/app/plugin/core/debug/gui/tracermi/launcher/TraceRmiLauncherServicePluginScreenShots.java

@@ -65,7 +65,7 @@ public class TraceRmiLauncherServicePluginScreenShots extends GhidraScreenShotGe
 
 		TraceRmiLaunchOffer offer = servicePlugin.getOffers(null)
 				.stream()
-				.filter(o -> "raw gdb".equals(o.getTitle()))
+				.filter(o -> "gdb".equals(o.getTitle()))
 				.findAny()
 				.orElseThrow();