Note:
The following is a particularly common breakpoint:
(idb) stop in main
[#1: stop in int main(void)]
(idb) break main
Breakpoint 1 at 0x8052e0f: file src/x_list.cxx, line 182.
This command tells the debugger that when execution enters the function main, you want the debugger to suspend execution and return control to you.
The debugger responds to a breakpoint command by displaying how it recorded the request internally. The debugger assigns a number to the breakpoint (in this case, it is 1), which it uses later to refer to that breakpoint. The debugger does not just repeat the command as you entered it; it provides a more complete description of the function main to help you confirm that it has correctly identified the function you meant.
Later, after you cause the program to execute, if that event occurs, the debugger reports the event and then prompts you for what to do next. For example:
(idb) run
[1] stopped at [int main(void):182 0x08052e0f]
182 List<Node> nodeList;
(idb) run
Starting program: /home/user/examples/x_list
Breakpoint 1, main () at src/x_list.cxx:182
182 List<Node> nodeList;
Both the event part and the action part of a breakpoint definition command consist of several subparts:
breakpoint_definition_command
[ quiet ]
[ thread_filter ]
[ logical_filter ]
where the detector, thread_filter (if specified), and logical_filter (if specified) collectively specify the event part, and the disposition, quiet (if specified) and breakpoint_actions (if specified) collectively specify the action part.
Note:
Additional obsolete forms of breakpoint definition are retained only for backward compatibility with earlier versions of the debugger. These forms are explained later. The obsolete forms may be eliminated in a future release.
There are three distinct points in time at which a breakpoint definition has an effect:
When the command is entered
The command is parsed, names and expressions that occur in any of the event parts are evaluated, and the breakpoint actions are parsed and checked for correctness (but not evaluated).
When the debugger initiates program execution
For each breakpoint that is not disabled, appropriate modifications are made to the program to enable detection of the specified event.
When a detector triggers during program execution
The thread filter specification (if present) and logical filter (if present) are evaluated to determine whether the breakpoint as a whole has triggered. If not, then execution is resumed (silently). If so, the breakpoint actions are performed, after which execution stops or resumes according to the specified disposition.