Note:
You can use place detectors to determine when execution reaches a particular place or location in your program:
place_detector
: in function_name
| in all function_name
| pc address_expression
| at line_specifier
The in function_name detector specifies the event where execution reaches the entry of the named function. For example:
If the function name is ambiguous (more than one function can match the name in some languages, including C++), the debugger prompts you with a list of alternatives from which to choose.
(idb) stop in foo
Select from
----------------------------------------------------
1 int C::foo(double*)
2 void C::foo(float)
3 void C::foo(int)
4 void C::foo(void)
5 None of the above
----------------------------------------------------
2
[#4: stop in void C::foo(float)]
If you choose the last option ("None of the above"), then no function is selected and no breakpoint is defined.
The in all function_name detector is the same as in function_name except that it specifies all of the functions that match the given name, whether one or more:
(idb) stop in all foo
[#3: stop in all foo]
The pc address_expression detector specifies the event where execution reaches the given machine address:
(idb) stop pc $pc
[#7: stop PC == 0x80534b4]
The at line_specifier detector specifies the event where code associated with a particular line of the source is reached:
(idb) stop at 190
[#8: stop at "src/x_list.cxx":190]
If no code is associated with the given line number, the debugger finds and substitutes the closest higher line number that has associated code.
The every procedure entry detector specifies that a breakpoint should be established for every function entry point in the program.
(idb) stop every procedure entry
[#9: stop every procedure entry]
Note:
This command can be very time consuming because it searches your entire program - including all shared libraries that it references - and establishes breakpoints for every entry point in every executable image. This can also considerably slow execution of your program as it runs.
A disadvantage of this command is that it establishes breakpoints for hundreds or even thousands of entry points about which you have little or no information. For example, if you use stop every proc entry immediately after loading a program and then run it, the debugger will stop or trace over 100 entry points before reaching your main entry point. About the only thing that you can do if execution stops at most such unknown places is continue until some function relevant to your debugging is reached.
The every instruction detector specifies a breakpoint for every instruction in your entire program:
(idb) stop every instruction
[#10: stop every instruction]
When used with the stop disposition, a subsequent continue behaves essentially the same as a step by instruction command (see stepi).
When used with the when disposition, subsequent next and step commands allow you to trace all of the instructions that are executed as a result of those stepping commands. Beware that even when next is used to step over a called routine, the trace output includes all of the instructions that are executed within the called routine (and any routines that it calls).
Note:
This command will slow execution of your program considerably.
The detector expression (that is, an expression not preceded by one of the keywords in, at, or pc) specifies either a function name or line number depending on how the expression is parsed and evaluated. An expression that evaluates to the name of a function is handled just like the equivalent command that uses in in the detector; otherwise, it is handled like the equivalent command that uses at in the detector.