The action part of a breakpoint command specifies actions to be performed when the event part has triggered (including passing any thread and/or logical filters):
breakpoint_actions
: { action_list }
action_list
: command
| command ;
| command ;...
Pay special attention to the following commands within the action list:
The following debugger commands behave differently in some fashion when used within a breakpoint action list:
Simple stop
A simple_stop_command is a stop without any detector or other parameters:
simple_stop_command
: stop
If used within a breakpoint action list, it specifies that the disposition for the breakpoint should be to stop after completion of action list processing, even if the breakpoint was specified with the when disposition. If used outside an action list, it has no effect.
A simple stop command does not terminate action list processing; it only affects the disposition that applies later. For example:
(idb) when in List<Node>::print { stop; print "*** stopped ***" }
[#6: when in void List<Node>::print(void) { stop; print "*** stopped ***" }]
(idb) cont
[6] when [void List<Node>::print(void):162 0x0804c5e6]
*** stopped ***
[6] stopped at [void List<Node>::print(void):162 0x0804c5e6]
162 Node* currentNode = _firstNode;
History
The history command does not display commands that are performed as part of the action list of a breakpoint.
You must be very careful when using some commands in breakpoint action lists. The following commands cause the debugger to resume execution of your program in the midst of action list processing:
It is easy in such cases to lose track of just what state breakpoint processing is really in or where you really are in your program. Such confusion may mislead or misdirect your debugging effort. For further discussion, see the section on Recursive breakpoints.
You should avoid altogether some commands in breakpoint action lists. The following are commands that directly or indirectly change the process that the debugger is controlling:
The debugger does not explicitly prohibit these commands, but their behavior within action lists is implementation-defined and subject to change from release to release. In very specialized cases, you may be able to obtain useful results by using them in action lists, but do not expect the same behavior over the long term.