During the course of a debugging session, you may find that a breakpoint has outlived its usefulness. If you're sure the breakpoint will no longer be needed, you can delete it.
It may also be the case that you think the breakpoint can be of use to you later on during the debugging session. Perhaps you'd rather not delete the breakpoint, but instead, cook things up so that for the time being the debugger will skip breaks at that point in your code. This is called disabling a breakpoint. You can re-enable it later if/when it becomes useful again.
This section covers deleting and disabling breakpoints. Everything mentioned applies to watchpoints as well.
If the breakpoint in question is truly no longer needed (perhaps that particular bug was fixed!) then you can delete that breakpoint. There are two commands that are used to delete breakpoints in GDB. The delete command is used to delete breakpoints based on their identifier, and the clear command is used to delete breakpoints using the same syntax you use to create breakpoints, as discussed in Setting Breakpoints in GDB.
deletebreakpoint_listDeletes breakpoints using their numeric identifiers (which were explained in Keeping Track of Breakpoints). It can be a single number, such as
delete 2which deletes the second breakpoint, or a list of numbers, likedelete 2 4which deletes the second and fourth breakpoints.deleteDeletes all breakpoints. GDB will ask you to confirm this operation unless you issue the
set confirm offcommand, which can also be placed in your .gdbinit startup file.clearClears a breakpoint at the next instruction that GDB will execute. This method is useful when you want to delete the breakpoint that GDB has just reached.
clearfunctionclearfilename:functionclearline_numberclearfilename:line_numberThese clear a breakpoint based on its location and work analogously to the
breakcounterparts.For example, suppose you set a breakpoint at the entry of
foo()with:(gdb) break foo Breakpoint 2 at 0x804843a: file test.c, line 22.
You can delete that breakpoint either with
(gdb) clear foo Deleted breakpoint 2
or with
(gdb) delete 2 Deleted breakpoint 2
Each breakpoint can be enabled or disabled. GDB will pause the program's execution only when it hits an enabled breakpoint; it ignores disabled breakpoints. By default, breakpoints start life as being enabled.
Why would you want to disable breakpoints? During the course of a debugging session, you may collect a large number of breakpoints. For loop structures or functions that repeat often, it can be extremely inconvenient for GDB to break so often. If you want to keep the breakpoints for later use but don't want GDB to stop execution for the time being, you can disable them and enable them later.
You disable a breakpoint with the disable breakpoint-list command and enable a breakpoint with the enable breakpoint-list command, where breakpoint-list is a space-separated list of one or more breakpoint identifiers. For example,
(gdb) disable 3
will disable the third breakpoint. Similarly,
(gdb) enable 1 5
will enable the first and fifth breakpoints.
Issuing the disable command without any arguments will disable all existing breakpoints. Similarly, the enable command with no arguments will enable all existing breakpoints.
There's also an enable once command that will cause a breakpoint to become disabled after the next time it causes GDB to pause execution. The syntax is:
enable once breakpoint-listFor example, enable once 3 will cause breakpoint 3 to become disabled the next time it causes GDB to stop execution of your program. It's very similar to the tbreak command, but it disables rather than deletes when the breakpoint is encountered.
Deleting breakpoints in DDD is just as easy as setting them. Position the cursor over the red stop sign and right-click the mouse, as you would to set a breakpoint. One of the options in the pop-up menu will be Delete Breakpoint. Hold down the right mouse button and drag the mouse down until this option is highlighted. Then release the button and you'll see the red stop sign disappear, indicating that the breakpoint was deleted.
Disabling breakpoints with DDD is very similar to deleting them. Rightclick and hold the red stop sign, and select Disable Breakpoint. The red stop sign will turn gray, indicating that the breakpoint is still there but is disabled for now.
Your other option is to use DDD's Breakpoints and Watchpoints window, shown in Figure 2-1. You can click a breakpoint entry there to highlight it, and then select Delete, Disable, or Enable.
In fact, you can highlight several entries in that window by dragging the mouse over them, as seen in Figure 2-3. You thus can delete, disable, or enable multiple breakpoints at once.
After clicking Delete in the breakpoints window, the screen looks like Figure 2-4. Sure enough, two of the old breakpoints are gone now.
As with DDD, you can delete or disable a breakpoint in Eclipse by right-clicking the breakpoint symbol in the line in question. A menu will pop up, shown in Figure 2-5. Note that the Toggle option means to delete the breakpoint, while Disable/Enable means the obvious.
Similar to DDD's breakpoints window, Eclipse has its Breakpoints view, which you can see in the upper-right portion of Figure 2-5. Unlike the DDD case, in which we needed to request the Breakpoints and Watchpoints window, Eclipse's Breakpoints view is automatically displayed in the Debug perspective. (You can hide it, though, if you are short on screen space, by clicking the X in its right-hand corner. If you want to get it back later, select Window | Show Views | Breakpoints.)
One nice aspect of the Eclipse Breakpoints view is that you can click the double X (Remove All Breakpoints) icon. The need for this occurs more often than you might guess. At some points in a long debugging session, you may find that none of the breakpoints you set earlier is now useful, and thus want to delete them all.
DDD has another really nice feature: drag-and-drop breakpoints. Left-click and hold a breakpoint stop sign in the Source Window. As long as you keep the left button pressed, you can drag the breakpoint to another location within your source code. What happens "behind the scenes" is that DDD deletes the original breakpoint and sets a new breakpoint with the same attributes. As a result, you'll find that the new breakpoint is entirely equivalent to the old breakpoint, except for its numeric identifier. Of course you can do this with GDB as well, but DDD expedites the process.
Figure 2-6 illustrates this—it is a snapshot taken in the midst of the breakpoint-move operation. There had been a breakpoint at the line
if (new_y < y[i]) {which we wished to move to the line
scoot_over(j);
We clicked on the stop sign at that old line and dragged it to the new line. In the picture, we had not yet released the mouse button, so the original stop sign was still there, and a "hollow" stop sign appeared on the new line. Upon our release of the mouse button, the stop sign at the old line disappeared and the one at the new line filled out.
Why is this so useful? First of all, if you are in a situation in which you want to delete one breakpoint and add another, this does both operations in one fell swoop. But more importantly, as noted earlier in Persistence of Breakpoints, when you add or delete source code lines, the line numbers of some remaining lines change, thus "shifting" existing breakpoints to lines at which you did not intend to have one. In GDB, this necessitates your doing a delete-breakpoint and new-breakpoint action at each of the affected breakpoints. This is tedious, especially if some of them had conditions attached to them.
But in DDD, you can simply drag the stop sign icon to the new locations—very nice and convenient.
One of DDD's really nice features is Undo/Redo, accessed by clicking Edit. As an example, consider the situation in Figures Figure 2-3 and Figure 2-4. Suppose you suddenly realize that you did not want to delete those two breakpoints—maybe you just wished to disable them. You can select Edit | Undo Delete, shown in Figure 2-7. (You could also click Undo in the Command Tool, but going through Edit has the advantage that DDD will remind us what will be undone.)
