# A Tour of the Debugger

This module assumes you have completed the [Getting Started](A1-GettingStarted.md) module.
If not, please go back.

This module will briefly introduce each window in the Ghidra Debugger.
We assume some familiarity with trap-and-trace debugging.
If you have not used GDB or a similar debugger before, you may find the Ghidra Debugger difficult to grasp.

If you would like your tool to look more or less like the one presented in the screenshot here,
launch `termmines` from the Debugger using GDB.

## The Debugger Tool

Like the CodeBrowser tool, the Debugger tool is a preconfigured collection of plugins and panels that present Ghidra's dynamic analysis features.
You may re-configure, save, export, import, etc. the tool to fit your preferences.
For reference, here is a screenshot of the default configuration after launching `termmines`:

![Debugger tool after launching termmines](images/GettingStarted_DisassemblyAfterLaunch.png)

### Toolbar

Many of the buttons in the global toolbar are the same as in the CodeBrowser.
Coincidentally, in the screenshot, the debugger-specific buttons start just above the Dynamic Listing in the global toolbar.
They are:

* ![launch button](images/debugger.png) **Launch**:
  This launches the current program (from the Static Listing) using a suitable back-end debugger.
  The drop-down menu provides a selection of previously-used launchers and a sub-menu of all available launchers.
  Clicking the button will use the most recent configuration, whether or not it succeeded.
* ![emulate button](images/process.png) **Emulate**:
  To be covered in a later module.
  This will load the current program (from the Static Listing) into the emulator.
* ![mode button](images/record.png) **Control Mode**:
  This drop-down menu sets the mode of the controls and machine state edits.
  By default, all actions are directed to the back-end debugger.
* ![resume button](images/resume.png) **Resume**:
  Resume execution.
  This is equivalent to `continue` in GDB.
* ![interrupt button](images/interrupt.png) **Interrupt**:
  Interrupt, suspend, pause, break, etc.
  This is equivalent to **`CTRL`-`C`** or `interrupt` in GDB.
* ![step into button](images/stepinto.png) **Step Into**, ![step over button](images/stepover.png) **Step Over**, ![step out button](images/stepout.png) **Step Out**, ![step last button](images/steplast.png) **Step [Extended]**:
  These buttons step in various ways.
  In order, the equivalent commands in GDB are `stepi`, `nexti`, and `finish`.
  Step [Extended] represents additional step commands supported by the back end. GDB provides **Advance** and **Return**.
* ![kill button](images/kill.png) **Kill**:
  Kill, terminate, etc.
  This is equivalent to `kill` in GDB.
* ![disconnect button](images/disconnect.png) **Disconnect**:
  Disconnect from the back-end debugger.
  Typically, this will also end the session.
  It is equivalent to `quit` in GDB.

### Windows

Starting at the top left and working clockwise, the windows are:

* The **Debug Console** window:
  (Not to be confused with the CodeBrowser's Console window.)
  This lists problems, diagnostics, progress, and recommendations throughout the tool.
  Some problems are presented with remedial actions, which may expedite your workflow or aid in troubleshooting.
* The **Connections** window:
  This is stacked below the Debug Console.
  This lists active sessions or connections.
  From here, you can establish new sessions or terminate existing sessions.
* The **Dynamic Listing** window:
  This is the primary means of examining the instructions being executed.
  By default, it follows the program counter and disassembles from there until the next control transfer instruction.
  It supports many of the same operations as the Static Listing, including patching.
  The nearest equivalent in GDB is something like `x/10i $pc`.
  The tabs at the top list the active traces.
  Traces with a ![record](images/record.png) icon represent live targets.
  The nearest equivalent to the tabs in GDB is `info inferiors`.
* The **Breakpoints** window:
  This is on the right.
  It lists and manages the breakpoints among all open program databases and running targets.
  The nearest equivalent in GDB is `info break`.
* The **Registers** window:
  This is stacked below the Breakpoints window.
  It displays and edits the register values for the current thread.
  The nearest equivalent in GDB is `info registers`.
* The **Memory** window:
  This is stacked below the Breakpoints window.
  It displays the raw bytes of memory from the current trace or target.
  It supports many of the same operations as the CodeBrowser's Bytes window, including patching.
* The **Decompiler** window:
  While not a dynamic analysis window, it bears mentioning how this operates with the Debugger.
  It is stacked below the Breakpoints window, more or less in the same place as in the CodeBrowser.
  The Dynamic listing strives to synchronize Ghidra's static analysis windows with the dynamic target.
  So long as the correct program database is imported and mapped at the program counter, this window should display decompilation of the function containing it.
* The **Modules** window:
  This is stacked below the Registers window.
  It displays the images (and sections, if applicable) loaded by the target.
  The equivalent in GDB is `maintenance info sections`.
  Note that this differs from the Regions window.
* The **Terminal** window:
  This is on the bottom right.
  This is a terminal emulator providing a command-line interface to the back-end debugger and/or target I/O.
  It is useful for diagnostics or for issuing commands that do not have a button in the GUI.
  Some may also prefer to command the debugger from here rather than the GUI.
  In some configurations, the target may have its own Terminal, separate from the back-end debugger's.
* The **Threads** window:
  This is stacked below the Terminal window.
  It lists the threads in the current target.
  The nearest equivalent in GDB is `info threads`.
* The **Time** window:
  This is stacked below the Terminal window.
  This lists the events and snapshots taken of the current target.
* The **Static Mappings** window:
  This is stacked below the Terminal window.
  It lists mappings from the current trace (dynamic address ranges) to program databases (static address ranges).
  Generally, this list is populated automatically, but may still be useful for diagnostics or manual mapping.
* The **Stack** window:
  This is on the bottom left.
  It lists the stack frames for the current thread.
  The equivalent in GDB is `backtrace`.
* The **Watches** window:
  This is stacked below the Stack window &mdash; pun not intended.
  It manages current watches.
  These are *not* watchpoints, but rather expressions or variables whose values you wish to display.
  To manage watchpoints, use the Breakpoints window or the Terminal.
  The nearest equivalent in GDB is `display`.
* The **Regio