(ladebug) list 43,50
43 PERFORM LOOK-BACK VARYING SUB-1 FROM 20 BY -1
44 UNTIL TEMP-CHAR (SUB-1) NOT = SPACE.
45 MOVE SUB-1 TO CHARCT.
46 PERFORM MOVE-IT VARYING SUB-2 FROM 1 BY 1 UNTIL SUB-1 = 0.
47 MOVE HOLD-WORD TO TEMP-WORD.
48 MOVE-IT.
49 MOVE TEMP-CHAR (SUB-1) TO HOLD-CHAR (SUB-2).
50 SUBTRACT 1 FROM SUB-1.
(ladebug)
|
Example 2-2 uses the list command to display the first 25 lines of an Ada program.
| Example 2-2 Listing Source Code By Counting from a Starting Line |
|---|
(ladebug) list 1:25
1 with TEXT_IO; use TEXT_IO;
2 with INTEGER_TEXT_IO; use INTEGER_TEXT_IO;
3 with FLOAT_TEXT_IO; use FLOAT_TEXT_IO;
4 procedure TEST is
5
6 procedure P (I : INTEGER);
7 procedure P (F : FLOAT);
8
9 procedure P (I : INTEGER) is
10 TWO : constant := 2;
11 begin
12 PUT (I * TWO);
13 NEW_LINE;
14 end;
15
16 procedure P (F : FLOAT) is
17 begin
18 PUT(F);
19 NEW_LINE;
20 end;
21
22 begin
23 P(5);
24 P(6.0);
25 end;
(ladebug)
|
If the source file is not in the current directory, you can enter a
use command to add directories to the
list of directories the debugger will search.
2.1.1 Displaying Source Code Contained in Another Module
To display source code contained in another module or source file:
- Choose File:Browse Source... on the Main Window. The Browse Source dialog box appears listing your program file. See Figure 2-2.
- Double click on the image to get a list of modules.
- Double click on the name of the module or source file containing the routine of interest. The names of the program's modules are displayed (indented) under the file name, and the Display Source button is now highlighted.
- Click on the name of the module whose source code you want to display.
- Click on Display Source. The source display in the Main Window now displays the module's source code.
Section 2.5 describes an alternative way to display routine source code for routines currently active on the call stack using the Call Stack menu.
The Browse Source dialog box displays information in a hierarchical form about all the binary files in your application. For each binary file, it displays information about the modules contained in the binary. For each module, a list of routines in that module can be displayed.
You can manipulate the Browse Source display by clicking on menu items in the Browse Source pop-up menus.
Figure 2-2 Displaying Source Code in Another Routine
2.1.2 Making Source Code Available for Display
In certain cases, the debugger cannot display source code. Possible causes are:
- The source file has not been compiled with the -g compiler option.
- Execution might be paused within a system or library routine for which no symbolic information is intended to be available. In such cases you can quickly return execution to the calling routine by clicking one or more times on the Return push button on the push-button panel (see Section 3.2.4).
- The source file might have been moved to a different directory after it was compiled. See the use command in the Command Reference section, which explains how to tell the debugger where to look for source files.
If the debugger cannot find source code for a display, it tries to
display the source code for the next routine on the call stack for
which source code is available. If the debugger can display source code
for such a routine, the current-location pointer is cleared. The
pointer then marks the source line to which execution returns in the
calling routine.
2.2 Accessing Program Variables
This section provides some general information about accessing program variables while debugging.
If your program was optimized during compilation, you might not have access to certain variables while debugging. When you compile a program for debugging, it is best to disable optimization if possible (see Section 1.6.1).
Before you check on the value of a variable, always execute the program beyond the point where the variable is declared and initialized. The value contained in any uninitialized variable should be considered invalid.
In most cases, the debugger resolves symbol ambiguities automatically,
using the scope and visibility rules of the source programming language.
2.2.1 How the Debugger Searches for Variables and Other Symbols
Symbol ambiguities can occur when a symbol is defined in more than one routine or other program unit.
In most cases, the debugger automatically resolves symbol ambiguities. First, it uses the scope and visibility rules of the currently set language. The debugger uses the ordering of routine calls on the call stack to resolve symbol ambiguities.
In some cases, however, the debugger might respond as follows when you specify a symbol that is defined multiple times:
- It might issue a "symbol not unique" message because it is not able to determine the particular declaration of the symbol that you intended.
- It might reference the symbol declaration that is visible in the current scope, instead of the declaration you want.
To resolve such problems, you must specify a scope where the debugger searches for the declaration of the symbol you want:
- If the different declarations of the symbol are within routines that are currently active on the call stack, use the Call Stack menu on the Main window to reset the current scope (see Section 2.5).
- Otherwise, enter the appropriate command at the command prompt
(examine or monitor, for example), specifying a pathname
prefix with the symbol. For example, if the variable x is defined in two routines named counter and swap,
the following command uses the path name swap\x to specify the declaration of x that is in routine swap:
(ladebug) examine swap\x
2.2.2 GUI Options for Selecting and Changing Variables and Values
Table 2-1 describes the options available in the GUI that you can use for selecting and changing variables and values.
| Option | Attributes |
|---|---|
| Local Variables View |
|
| Print button |
|
| Monitor View |
|
| Print Dialog Box | Allows for typecasting. |
| Assign Dialog Box | Allows for typecasting. |
You can also enter commands in the command interface to select
variables and change their values.
2.2.3 Selecting Variable Names from Windows
Use the following techniques to select variable names from windows.
When selecting names, follow the syntax of the source programming language:
- To specify a scalar (nonaggregate) variable, such as an integer, real, Boolean, or enumeration type, select the variable's name.
- To specify an entire aggregate, such as array or structure (record), select the variable's name.
- To specify a single element of an aggregate variable, select the
entity using the language syntax. For example:
- The string arr2[7] specifies element 7 of array arr2 in the C language.
- To specify the object designated by a pointer variable, select the entity following the language syntax. For example, the string *int_point specifies the object designated by pointer int_point in the C language.
Select character strings from windows in one of the following ways:
- To select a string delimited by blank spaces, use the standard window interface word-selection technique in any window: position the pointer on that string and then double click on MB1.
- To select an arbitrary character string, use the standard window interface text-selection technique in any window: position the pointer on the first character, press and hold MB1 while dragging the pointer over the string, and then release MB1.
- You also have the option of using language-sensitive text
selection in the debugger source display. To select a string delimited
by language-dependent identifier boundaries, position the pointer on
that string and press Ctrl/MB1.
For example, suppose the source display contains the character string arr2[m], then:- To select arr2, position the pointer on arr2 and press Ctrl/MB1.
- To select m, position the pointer on m and press Ctrl/MB1.
2.2.4 Listing and Displaying Variables
You can use the dump command in the command interface to list an active function's local variables and parameters.
Example 2-3 shows how to obtain a dump of all active functions.
| Example 2-3 Displaying Information on Each Activation Level |
|---|
(ladebug) dump >0 0x120001224 in factorial(i=1) sample.c:13 i=1 f=0 (ladebug) |
The function factorial has the parameter i but it has no local variables. The function main has two local variables, i and f.
Your program may declare a particular symbol more than once. For example, in the program sample.c the symbol i is declared in the function main and again in the function factorial.
Because the debugger extends the visibility and scope rules of the programming language, the debugger may have access to more than one declaration of a symbol name. You can use the which command in the command interface to determine which declaration exists in the current context. The which command displays the variable with its scope information fully qualified.
The whereis command lists all declarations of a variable together with each declaration's scope information fully qualified. Example 2-4 shows how to use the whereis and which commands to determine a variable's scope.
| Example 2-4 Displaying a Variable's Scope |
|---|
(ladebug) where
>0 0x120001230 in factorial(i=1) sample.c:14
#1 0x12000124c in factorial(i=2) sample.c:16
#2 0x120001194 in main() sample.c:5
(ladebug) print i
1
(ladebug) which i
"sample.c"`factorial.i
(ladebug) whereis i
"sample.c"`factorial.i
"sample.c"`main.i
(ladebug) func main
main in sample.c line No. 5:
5 f = factorial(i);
(ladebug) print i
2
(ladebug) which i
"sample.c"`main`i
(ladebug)
|
The whereis command is useful for obtaining information needed to differentiate overloaded identifiers that are in different units, or within different routines in the same unit.
Example 2-5 shows how to set breakpoints in two Ada program routines, both named DO_PRINT.
| Example 2-5 Determining Overloaded Identifiers |
|---|
(ladebug) whereis do_print "overload.ada"`OVERLOAD`DO_PRINT "overload.ada"`OVERLOAD`INNER`DO_PRINT (ladebug) stop in "overload.ada"`OVERLOAD`DO_PRINT [#1: stop in DO_PRINT ] (ladebug) stop in "overload.ada"`OVERLOAD`INNER`DO_PRINT [#2: stop in DO_PRINT ] (ladebug) |
| Previous | Next | Contents | Index |