Using the Debug view

With the Debug view, you can manage the debugging of a program. It displays the stack for the suspended threads for each target you are debugging. Debug targets (associated with threads and stack frames) display in the Debug view for each program or application that you are debugging.

About this task

In the Debug view, each thread in your program is displayed as a node in the tree. A typical debug target in the Debug view is described according to this diagram:

In the Debug view, launches used to start the debug session for the program are displayed at the top node level (pointer A. in the diagram). Beneath the launch, a node representing the debug engine is displayed (pointer B. in the diagram). Each thread in your program is then displayed (pointer C. in the diagram). When program execution stops, by default, the node for the stopping thread automatically expands to show its stack frame(s) (pointer D. in the diagram). If you manually expand other threads, these threads will automatically expand the next time the program suspends. Finally, a node representing the process and program being debugged is displayed (pointer E. in the diagram).

Notes:

For single-threaded applications (those built without libpthreads.a), the thread ID that is displayed in the Debug view is always a kernel thread ID. This is normally a large number.
For multithreaded applications (those built with libpthreads.a), the thread ID that is displayed in the Debug view is the pthread ID. These are normally small numbers. A thread with a very large thread ID indicates a kernel thread that is not currently associated with a pthread. This usually occurs if the application has received an asynchronous signal, such as SIGSTOP. These threads will disappear when the signal has been handled.
If you choose to follow the child process after a call to fork() in a multithreaded process, the debugger will only debug the single kernel thread that exists in the child process. The ID of this thread will be that of a kernel thread.
Paragraph frame is not supported if the load module is complied with OPT.

When program execution is suspended, the source for the selected stack frame opens in the editor, highlighting the source line that the program is about to execute. If there are many threads in the program, the stack for the thread that caused the stop may be scrolled off the end of the debug frame.

The sections that follow explain the actions that can be performed using the toolbar icons in the Debug View. As shown in the diagram below, the Debug view can also be used for setting the debugger daemon. For information about this, see the related topic about listening for debug engines.

Running, terminating, and detaching a program

About this task

You can perform these basic debug actions in the Debug view:

To run your application, click Resume or press F8.
To terminate the debug session, click Terminate () or press Shift+F8 - or right-click the debug target (or one of its threads or stacks) that you want to terminate, and choose one of the terminate actions.
To detach from the program and leave it running, click Disconnect (). This action might be unavailable, depending on how the program you are debugging was started.

Stepping through a program

About this task

When a thread is suspended, the step controls can be used to step through the execution of the program line-by-line. While performing a step operation, if a breakpoint or event is encountered, execution suspends at the breakpoint or event, and the step operation ends. You can use step commands to step through your program a single instruction or location at a time.

The following step commands are available:

Step Over ()(F6): When you issue a step over, the program steps to the next source line.
Step Into ()(F5): When you issue a step into, your program will step to the next statement. If the current line contains a call to another function, the debugger will stop in that function.
The behavior of this command is affected by the Use Step Filters action ()(Shift+F5). If the filter is off (push button not selected), the debugger will stop in a called function even if it does not contain debug information and disassembly must be displayed. If the filter is on (push button selected) , the debugger will only stop in the called function if source can be displayed. If source cannot be displayed, it behaves as though you had issued a Step Over. The DER_DBG_ STEP_DEBUG debug engine environment variable affects the behavior of the Use Step Filters action.

Note: For PL/I and COBOL, the step into action will typically behave as though the step filter action is always on. When debugging programs written in these languages, the debugger will attempt to stop in source code.
Step Return ()(F7): When you issue a step return, your program runs to the point in the calling program immediately after the call to the current function. You will normally stop at the location following the calling instruction. If the calling program has debug information, this may be in the middle of a source line.
Animated Step Into(): When you issue this action, the debugger issues a step into action repeatedly. You can control the delay between each step by selecting the Animated Step Into action again.