Debugger: Breakpoints

The breakpoints window tabulates and manipulates breakpoints among all live and traced targets. Only address-based breakpoints are tabulated. For other traps, e.g., "break on exception," see the Objects Window. Breakpoints can also be manipulated from address-based views, especially the disassembly listings. See Breakpoints in the Listings. Display of breakpoints in other views, e.g., the decompiler, is not yet implemented.

Individual breakpoint locations from among the targets are consolidated into logical breakpoints, based on their addresses in the static listing. The static locations are typically stored as bookmarks in their respective Ghidra programs, comprising the current breakpoint set. See the Static Mappings window for the finer details of address mapping. A breakpoint which cannot be mapped to a static address becomes its own logical breakpoint at its dynamic address. The top table of the provider displays logical breakpoints; the bottom table displays breakpoint locations. NOTE: The breakpoints window cannot display or manipulate breakpoints from a target until that target is recorded into a trace. Furthermore, dead traces are not included. Nor are breakpoints from the past included, even when viewing past machine state.

Depending on what is supported by the connected debugger, breakpoints can trap a target when an address or range is executed, read, or written; using software or hardware mechanisms. In case of "read" or "write," debuggers may differ in terminology, e.g., GDB might call them "watchpoints," but Ghidra still calls these "breakpoints." Some debuggers allow the user to specify a breakpoint location other than by address, but ultimately each specification is realized by 0 or more addressable locations. To accommodate this, the Objects window will typically display a list of specifications, each listing its locations as children. However, the grouping of breakpoint locations into logical breakpoints by this manager is done without respect to the specifications. Often the specification is at a higher stratum than Ghidra natively understands, e.g., the source filename and line number, and so such specifications are not relevant. Note, however, that the model might not permit locations to be manipulated independently of their specification, which may limit how the manager can operate on each breakpoint location.

Because of the logical grouping of breakpoints, it is possible for a breakpoint to be in a mixed or inconsistent state. This happens quite commonly, e.g., when a breakpoint is placed in a Ghidra program before that program is mapped in any traced target. Once mapped in, the location of that breakpoint in the trace is computed and noted as missing. A logical breakpoint without any location in a trace (i.e., on an actual target) is called ineffective and is drawn in grey, e.g.: . An enabled logical breakpoint having a disabled location is called inconsistent and its icon will include an exclamation mark: . A disabled logical breakpoint having an enabled location is similarly inconsistent. Toggling an ineffective or inconsistent logical breakpoint enables and/or places all its locations, aiming for a consistent enabled state. Toggling it again disables all locations.

Tables and Columns

The top table, which lists logical breakpoints, has the following columns:

The bottom table, which lists breakpoint locations, has the following columns:

Breakpoint Actions

The primary purpose of this provider is to manipulate existing breakpoints. It provides the following actions to that end. Breakpoints can also be managed via the Breakpoint Marker Actions in the listings.

Enable

This action is available when one or more breakpoints or locations are selected. It enables each selected breakpoint. For any breakpoint that is already enabled, no action is taken.

Enable All Breakpoints

This action is always available. It enables every breakpoint. For any breakpoint that is already enabled, no action is taken.

Disable

This action is available when one or more breakpoints or locations are selected. It disables each selected breakpoint. For any breakpoint that is already disabled, no action is taken.

Disable All Breakpoints

This action is always available. It disables every breakpoint. For any breakpoint that is already disabled, no action is taken.

Make Breakpoints Effective

This action is available whenever there are mapped breakpoints with 0 locations, i.e., it corresponds to a target location where the breakpoint is still missing. It places such breakpoints where possible. This action is also offered as a resolution in the console. It appears in the log any time this action is available.

Clear

This action is available when one or more breakpoints or locations are selected. It clears (deletes) each selected breakpoint.

Clear All Breakpoints

This action is always available. Use with caution! It deletes every breakpoint.

Filter Actions

For organizing breakpoints the manager provides the following actions:

Filter to Current Trace

This toggle is always available. It filters the bottom table to those locations in the current trace only. Additionally, the "Locations" column of the top table will only count those in the current trace.

Filter to Breakpoint Selection

This action is always available. It filters the bottom table to those locations belonging to a selected breakpoint in the top table.