| does not leave an active breakpoint. If you use |
| break without an argument in the innermost |
| frame, GDB stops the next time it reaches the |
| current location; this may be useful inside loops. |
| GDB normally ignores breakpoints when it |
| resumes execution, until at least one instruction |
| has been executed. If it did not do this, you would |
| be unable to proceed past a breakpoint without |
| first disabling the breakpoint. This rule applies |
| whether or not the breakpoint already existed |
| when your program stopped. |
break ... if cond | Set a breakpoint with condition cond; evaluate |
| the expression cond each time the breakpoint is |
| reached, and stop only if the value is |
| nonzero―that is, if cond evaluates as true. '...' |
| stands for one of the possible arguments described |
| above (or no argument) specifying where to break. |
| See “Break conditions” (page 59), for more |
| information on breakpoint conditions. |
tbreak args | Set a breakpoint enabled only for one stop. args |
| are the same as for the break command, and the |
| breakpoint is set in the same way, but the |
| breakpoint is automatically deleted after the first |
| time your program stops there. See “Disabling |
| |
hbreak args | Set a |
| same as for the break command and the |
| breakpoint is set in the same way, but the |
| breakpoint requires hardware support and some |
| target hardware may not have this support. The |
| main purpose of this is EPROM/ROM code |
| debugging, so you can set a breakpoint at an |
| instruction without changing the instruction. This |
| can be used with the new |
| by SPARClite DSU and some |
| These targets will generate traps when a program |
| accesses some data or instruction address that is |
| assigned to the debug registers. However, the |
| hardware breakpoint registers can take a limited |
| number of breakpoints. For example, on the DSU, |
| only two data breakpoints can be set at a time, and |
| GDB will reject this command if more than two |
5.1 Breakpoints | 53 |