Search Docs:

Red Hat Docs  >  Manuals  >  GNUPro Toolkit Manuals  >

6. Debugging with Insight

The following documentation serves as a general reference for debugging with GNUPro Toolkit's graphical user interface, Insight. In addition to this information, see Insight's Help menu for discussion of general functionality and use of menus, buttons, or other features; see also Insight, GDB's Alternative Interface and the Examples of Debugging with Insight documentation in GNUPro Debugging Tools (see http://www.redhat.com/docs/manuals/gnupro/).

IMPORTANT

{Insight works as the default means for debugging; to disable

1. From a shell window, enter the following command:

   insight

   Insight launches, displaying the Source Window (figure \text\{Source Window the main window interface for Insight, {Source Window, the main window interface for Insight}}).

The menu selections in the Source Window are File, Run, View, Control, Plugin, Preferences, and Help. To work with the other windows for debugging purposes specific to your project, use the View menu or the buttons in the toolbar.

1. To open a specific file as a project for debugging, select File => in the Source Window. The file's contents will then pass to the GDB interpreter.

2. To start debugging, click the Run button (figure Run button) from the Source Window.

WARNING!

When debugging a target, do not click on the Run

When the debugger runs, the button turns into the Stop button (figure Stop button).

The Stop button interrupts the debugging process for a project, provided that the underlying hardware and protocols support such interruptions. Generally, machines that are connected to boards cannot interrupt programs on those boards. In such cases, a dialog box appears as a prompt asking if you want to abandon the session and if the debugger should detach from the target. For an embedded project, click Run; then click the Continue button (figure Continue button).

For more information on Insight, see its Help menu. For examples of debugging session procedures for using Insight, see the following documentation (the content assumes familiarity with debugging procedures).

• See Select and Examine a Source File,

• See Set Breakpoints and View Local Variables,

• See Set Breakpoints on Multiple Threads.

To specify how source code appears and to change debugging settings, from the Preferences menu, select Source.

When debugging remotely, you can find the processor name and identification coded of the target board by selecting Plugin => from the Source Window.

CPU Information, information which is obtained from the processor's response to the CPUID instruction (target changes with every target architecture for Insight; environment variables that you set help Insight automatically to determine this functionality). To add identification codes to the debugger's table of processors, see the GDB Internals documentation, distributed with the source code.

6.1 Select and Examine a Source File

To select a source file, or to specify what to display when examining a source file when debugging, use the following processes.

1. Select a source file from the file drop-down list with the Source Window (hello.c in figure Source file selection).

1. Select a function from the function drop-down list to the right of the file drop-down list, or type its name in the text field above the list to locate the function (in figure Search for Functions, see the executable line 11, where the main function displays).

1. Use the Enter key to repeat a previous search. Use the Shift and Enter keys simultaneously to search backwards.

2. Type @ with a number in the search text box in the top right of the Source Window. Press Enter. figure @ref{Figure {Searching for a specific,, {Searching for a specific} line in source code}, shows a jump to line 8 in the hello.c source file.

6.2 Set Breakpoints and View Local Variables

A breakpoint can be set at any executable line in a source file.

Executable lines are marked by a minus sign in the left margin of the Source Window. When the cursor is over a minus sign for an executable line, the cursor changes to a circle. When the cursor is in this state, a breakpoint can be set. The Breakpoints window is for managing the breakpoints: disabling them, enabling them, or erasing them; an enabled breakpoint is one for which the debugging session will stop, a disabled breakpoint is one which the debugging session ignores.

The following exercise steps you through setting four breakpoints in a function, as well as running the program and viewing changed values in local variables.

For more information about breakpoints, see the standard documentation for Insight: Insight, GDB's Alternative Interface and the Examples of Debugging with Insight documentation in GNUPro Debugging Tools; also see http://www.redhat.com/docs/manuals/gnupro/).

1. To set a breakpoint, have an active source file open in the Source Window, and, with the cursor over a minus sign on a line, click the left mouse button. When you click on the minus sign, a red square appears for the line, signifying a set breakpoint (see the highlighted line 15 in figure Results of setting breakpoint for line 17, for a set breakpoint).

Clicking the line again will remove the breakpoint.

1. Open the Breakpoints window (figure \text\{Breakpoints window, Breakpoints window}) using the Breakpoints button from the Source Window. See a line with a check box in the window appears showing that you set a breakpoint for a corresponding line in the Source Window frame. With the cursor over a breakpoint, a breakpoint information balloon displays in the Source Window (the information details the breakpoint, its address, its associated source file and line, its state, whether enabled, temporary, or erased, and the association to all threads for which the breakpoint will cause a stop; see also Set Breakpoints on Multiple Threads, for details about threads).

1. The debugger ignores disabled breakpoints, lines indicated having a black square over them in the Source Window frame (see line 17 in figure Results of setting breakpoint for line 17). Click on a breakpoint to disable it. figure @ref{Figure {Results of disabling a breakpoint at,, {Results of disabling a breakpoint at} line 17}, shows the results in the Breakpoints window of disabling a breakpoint. Re-enable a breakpoint at a line by clicking on the check box in the Breakpoints window. Once a breakpoint is enabled for a line, it will again have a red square in the Source Window frame.

1. Repeat the process to set breakpoints at specific lines.

2. Click Run in the Source Window to start the executable. The debugger runs until it finds a breakpoint. When the target stops at a breakpoint, the debugger highlights a line (see highlighted line 17 in figure @xref{Figure Executable after changing local variable's values,, Executable after changing local variable's values}, where the debugging stopped).

The following excersize illustrates how to view local variables, and use this information while using breakpoints:

1. Open the Local Variables window by clicking its button in the tool bar for the Source Window; the Local Variables window displays the values of the variables (see figure \text\{Local Variables window, Local Variables window}, for the b variable in hello.c).

1. Click the Continue button in the Source Window tool bar to move to the next breakpoint. The variables that changed value turn color in the Local Variables window (see results in figure \text\{Local Variables window after setting breakpoints, Local Variables window after setting breakpoints}, for the b variable in hello.c).

1. Click the Continue button two more times to step through the next two breakpoints (until execution stops at line 17) and see the values of the local variables change (compare results from hello.c in figure Results of setting breakpoint for line 17, and results in figure @xref{Figure Executable after changing local variable's values,, Executable after changing local variable's values}).

6.3 Set Breakpoints on Multiple Threads

You can select threads and set breakpoints on one or more threads when debugging a multi-threaded application with Insight.

WARNING!

{Working with multiple threads does not function similarly on

A process can have multiple threads running concurrently, each performing a different task, such as waiting for events or something time-consuming that a program does not need to complete before resuming. The thread debugging facility allows you to observe all threads while your program runs. However, whenever the debugging process is active, one thread in particular is always the focus of debugging. This thread is called the current thread. The precise semantics of threads and the use of threads differs depending on operating systems. In general, the threads of a single program are like multiple processes, except that they share one address space (that is, they can all examine and modify the same variables). Additionally, each thread has its own registers and execution stack and, perhaps, private memory.

1. In the Source Window, right click on an executable line without a breakpoint to open the breakpoint pop-up menu (figure \text\{Breakpoint pop-up menu in the Source Window, Breakpoint pop-up menu in the Source Window}).

1. Select Set Breakpoint on Thread(s) to display a window allowing you to choose the threads with which you set breakpoints. The Processes window (see figure Processes window with threads), available from the Source Window's View =>{} Threads List menu, displays all the available threads in the system and allows you to change the current thread.

For more general information about threads, see Debugging with GDB in GNUPro Debugging Tools (see http://www.redhat.com/docs/manuals/gnupro/)