Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Studio 12.3: Debugging a Program With dbx Oracle Solaris Studio 12.3 Information Library |
4. Viewing and Navigating To Code
5. Controlling Program Execution
6. Setting Breakpoints and Traces
8. Evaluating and Displaying Data
11. Debugging Multithreaded Applications
16. Debugging Fortran Using dbx
17. Debugging a Java Application With dbx
18. Debugging at the Machine-Instruction Level
19. Using dbx With the Korn Shell
20. Debugging Shared Libraries
The step command steps one source line or statement (stepping into calls that were compiled with the -g option).
The dbx step_events environment variable controls whether breakpoints are enabled during a step.
The dbx step_granularity environment variable controls granularity of source line stepping.
The dbx step_abflow environment variable controls whether dbx stops when it detects that “abnormal” control flow change is about to occur. Such control flow change can be caused by a call to siglongjmp() or longjmp() or an exception throw.
Single step one line (step into calls). With multithreaded programs when a function call is stepped over, all threads are implicitly resumed for the duration of that function call in order to avoid deadlock. Non-active threads cannot be stepped.
Single step n lines (step into calls).
Step up and out of the current function.
Deliver the given signal while stepping. If a signal handler exists for the signal, step into it if the signal handler was compiled with the -g option.
Step the given thread. Does not apply to step up.
Step the given LWP. Does not implicitly resume all LWPs when stepping over a function.
Attempts to step into function called from the current source code line. If function is not given, steps into the last function called, helping to avoid long sequences of step commands and step up commands. Examples of the last function are:
f()->s()-t()->last();
last(a() + b(c()->d()));
where:
n is the number of lines to step.
signal is the name of a signal.
thread_id is a thread ID.
lwp_id is an LWP ID.
function is a function name.
Only when an explicit lwp_id is given, the deadlock avoidance measure of the generic step command is defeated.
When executing the step tocommand, while an attempt is made to step into the last assembly call instruction or step into a function (if specified) in the current source code line, the call may not be taken due to a conditional branch. In a case where the call is not taken or there is no function call in the current source code line, the step to command steps over the current source code line. Take special consideration on user-defined operators when using the step to command.
See also stepi Command for machine-level stepping.
Single step one line (step into calls). With multithreaded programs when a method call is stepped over, all threads are implicitly resumed for the duration of that method call in order to avoid deadlock. Non-active threads cannot be stepped.
Single step n lines (step into calls).
Step up and out of the current method.
Step the given thread. Does not apply to step up.
Step the given LWP. Does not implicitly resume all LWPs when stepping over a method.