Each breakpoint has various attributes—its line number, the condition imposed on it (if any), its current enabled/disabled status, and so on. We showed in Keeping Track of Breakpoints a bit about keeping track of these attributes, and now we'll go into more detail.
As you saw in Breakpoint Lists in GDB, each breakpoint you create is assigned a unique integer identifier. The first breakpoint you set is assigned to '1', and each new breakpoint thereafter is assigned an integer one greater than the previously assigned identifier. Each breakpoint also has a number of attributes that control and fine-tune its behavior. Using the unique identifiers, you can adjust the attributes of each breakpoint individually.
You can use the info breakpoints command (abbreviated as i b) to obtain a listing of all the breakpoints you've set, along with their attributes. The output of info breakpoints will look more or less like this:
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x08048404 in main at int_swap.c:9
breakpoint already hit 1 time
2 breakpoint keep n 0x08048447 in main at int_swap.c:14
3 breakpoint keep y 0x08048460 in swap at int_swap.c:20
breakpoint already hit 1 time
4 hw watchpoint keep y counterLet's look at this output from info breakpoints in detail:
(Num):The breakpoint's unique identifier.
(Type):This field tells you whether the breakpoint is a breakpoint, watchpoint, or catchpoint.
(Disp):Each breakpoint has a disposition, which indicates what will happen to the breakpoint after the next time it causes GDB to pause the program's execution. There are three possible dispositions:
| keep The breakpoint will be unchanged after the next time it's reached. This is the default disposition of newly created breakpoints. |
del The breakpoint will be deleted after the next time it's reached. This disposition is assigned to any breakpoint you create with the tbreak command (see Setting Breakpoints in GDB). |
dis The breakpoint will be disabled the next time it's reached. This is set using the enable once command (see Disabling Breakpoints in GDB). |
(Enb):This field tells you whether the breakpoint is currently enabled or disabled.
(Address):This is the location in memory where the breakpoint is set. This would mainly be of use to assembly language programmers or people trying to debug an executable that wasn't compiled with an augmented symbol table.
(What):As discussed, each breakpoint lives at a particular line within your source code. The What field shows the line number and filename of the location of the breakpoint.
For watchpoints, this field shows which variable is being watched. This makes sense because a variable is actually a memory address with a name, and a memory address is a location.
As you can see, in addition to listing all the breakpoints and their attributes, the i b command also tells you how many times a particular breakpoint has caused GDB to halt execution of the program so far. If, for instance, you have a breakpoint within a loop, it will tell you at a glance how many iterations of the loop have been executed so far, which can be very useful.
As you saw in Figure 2-1, DDD's Breakpoints and Watchpoints window provides the same information as GDB's info breakpoints command. However, it is more convenient than GDB, in that you can display this window constantly (i.e., off to the side of your screen), thus avoiding issuing a command each time you want to view your breakpoints.
Again, as seen earlier (Figure 2-2), Eclipse's Breakpoints view constantly displays your breakpoints and their properties. Eclipse is a little less informative than DDD here, in that it does not tell you how many times a breakpoint has been hit so far (this information is not even in the Properties window).