| Previous | Contents | Index |
Ladebug does not support assignments to arrays, only single array
elements.
6.3.5 DIGITAL Fortran 90 Module Variables
To refer to a variable defined in a module, insert a dollar sign ($), the module name, and another dollar sign ($) before the variable name. For example, with a variable named J defined in a module named modfile (statement MODULE MODFILE), enter the following command to display its value:
(ladebug) list 5,7
5 USE MODFILE
6 INTEGER*4 J
7 CHARACTER*1 CHR
(ladebug) print $modfile$j
|
DIGITAL Fortran 90 supports two types of pointers:
% f90 -g -ladebug ptr.f90
% ladebug ./a.out
Welcome to the Ladebug Debugger Version x.y-zz
------------------
object file name: ./a.out
Reading symbolic information ...done
(ladebug)stop in ptr
[#1: stop in ptr ]
(ladebug) list 1:13
1 program ptr
2
3 integer, target :: x(3)
4 integer, pointer :: xp(:)
5
6 x = (/ 1, 2, 3/)
7 xp => x
8
9 print *, "x = ", x
10 print *, "xp = ", xp
11
12 end
(ladebug) run
[1] stopped at [ptr:6 0x120001838]
6 x = (/ 1, 2, 3/)
(ladebug) whatis x
integer*4 x (1:3)
|
Since xp has not been assigned to point to anything yet, it is still a generic pointer:
(ladebug) whatis xp
integer*4 (:) xp
(ladebug) S
stopped at [ptr:7 0x120001880]
7 xp => x
(ladebug)
stopped at [ptr:9 0x120001954]
9 print *, "x = ", x
(ladebug)
x = 1 2 3
stopped at [ptr:10 0x1200019c8]
10 print *, "xp = ", xp
(ladebug)
xp = 1 2 3
stopped at [ptr:12 0x120001ad8]
12 end
|
Now that xp points to x, it takes on the size, shape and values of x:
(ladebug) whatis xp integer*4 xp (1:3) (ladebug) print xp (1) 1 (2) 2 (3) 3 (ladebug) quit % |
The following example shows DIGITAL Fortran CRAY-style pointers displayed in their corresponding source form with a whatis command:
% f90 -g -ladebug cray.f90
% ladebug ./a.out
Welcome to the Ladebug Debugger Version x.y-zz
------------------
object file name: ./a.out
Reading symbolic information ...done
(ladebug) stop at 14
[#1: stop at "cray.f90":14 ]
(ladebug) run
[1] stopped at [cray:14 0x1200017e4]
14 end
(ladebug) whatis p
real*4 (1:10) pointer p
(ladebug) print p
0x140002c00 = (1) 10
(2) 20
(3) 30
(4) 40
(5) 50
(6) 60
(7) 70
(8) 80
(9) 90
(10) 100
(ladebug) l 1:14
1 program cray
2
3 real i(10)
4 pointer (p,i)
5
6 n = 5
7
8 p = malloc(sizeof(i(1))*n)
9
10 do j = 1,10
11 i(j) = 10*j
12 end do
13
> 14 end
(ladebug) quit
|
Ladebug supports COMPLEX, COMPLEX*8, and COMPLEX*16 variables and constants in expressions.
Consider the following Fortran program:
PROGRAM complextest
COMPLEX*8 C8 /(2.0,8.0)/
COMPLEX*16 C16 /(1.23,-4.56)/
REAL*4 R4 /2.0/
REAL*8 R8 /2.0/
REAL*16 R16 /2.0/
integer*2 i2 /2/
integer*4 i4 /2/
integer*8 i8 /2/
TYPE *, "C8=", C8
TYPE *, "C16=", C16
end
|
Ladebug supports basic arithmetic operators, display and assignment on variables and constants of the COMPLEX type. For example:
Welcome to the Ladebug Debugger Version x.y-zz
------------------
object file name: complex
Reading symbolic information ...done
(ladebug) stop in complextest
[#1: stop in complextest ]
(ladebug) run
[1] stopped at [complextest:15 0x1200017b4]
15 TYPE *, "C8=", C8
(ladebug) whatis c8
complex c8
(ladebug) whatis c16
double complex c16
(ladebug) print c8
(2, 8)
(ladebug) print c16
(1.23, -4.56)
(ladebug) whatis (-5,6.78E+12)
double complex
(ladebug) print (c8*c16)/(c16*c8)
(1, 0)
(ladebug) a c16=(-2.3E+10,4.5e-2)
(ladebug) print c16
(-23000000512, 0.04500000178813934)
(ladebug)
|
If a subprogram uses alternate entry points (ENTRY statement within the subprogram), Ladebug handles alternate entry points as a separate subprogram, including:
For example, the following is a fragment of a Fortran program and a debugging session:
program aep
call foo(1,2,3,4)
call bar(4,5,6)
end
subroutine foo(I,J,K,I1)
INTEGER*4 I,J,K,L,I1
write (6,*) 'Entered via foo: ', i, j, k, I1
write (6,*) '*****************************'
goto 1000
entry bar(J,K,L)
write (6,*) 'Entered via bar: ', j, k, l
write (6,*) '*****************************'
1000 write (6,*) 'Exiting foo & bar'
return
end
Welcome to the Ladebug Debugger Version x.y-zz
------------------
object file name: aep
Reading symbolic information ...done
(ladebug) stop in foo
[#1: stop in foo ]
(ladebug) stop in bar
[#2: stop in bar ]
(ladebug) status
#1 PC==0x120001868 in foo "aep.f":10 { break }
#2 PC==0x1200019ac in bar "aep.f":16 { break }
(ladebug) run
[1] stopped at [foo:10 0x120001868]
10 write (6,*) 'Entered via foo: ', i, j, k, I1
(ladebug) where
>0 0x120001868 in foo(I=1, J=2, K=3, I1=4) aep.f:10
#1 0x120001814 in aep() aep.f:3
#2 0x1200017b0 in main() for_main.c:203
(ladebug) c
Entered via foo: 1 2 3 4
*****************************
Exiting foo & bar
[2] stopped at [bar:16 0x1200019ac]
16 write (6,*) 'Entered via bar: ', j, k, l
(ladebug) where
>0 0x1200019ac in bar(J=4, K=5, L=6) aep.f:16
#1 0x12000182c in aep() aep.f:4
#2 0x1200017b0 in main() for_main.c:203
(ladebug) c
Entered via bar: 4 5 6
*****************************
Exiting foo & bar
Thread has finished executing
(ladebug) quit
|
Ladebug and the Tru64 UNIX operating system support the Fortran language with certain limitations, that are described in the following sections.
Be aware of the following data-type limitations when you debug a Fortran program:
The following limitations apply only to DIGITAL Fortran 90:
The Ladebug debugger lets you debug mixed-language programs. Program flow of control across subprograms written in different languages is transparent.
The debugger automatically identifies the language of the current subprogram or code segment on the basis of information embedded in the executable file. For example, if program execution is suspended in a subprogram in Fortran, the current language is Fortran. If the debugger stops the program in a C function, the current language becomes C. The current language determines for the debugger the valid expression syntax and the semantics used to evaluate an expression.
The debugger sets the $lang variable to the language of the current subprogram or code segment. By manually setting the $lang debugger variable, you can force the debugger to interpret expressions used in commands by the rules and semantics of a particular language. For example, you can check the current setting of $lang and change it as follows:
(ladebug) print $lang "C++" (ladebug) set $lang = "Fortran" |
When the debugger reaches the end of your program, the $lang variable is set to the language of the
main program.
6.7 Debugging a Program That Generates an Exception
If your program encounters an exception at run time, to make it easier to debug the program, recompile and relink with the following f90 flags or f77 flags before debugging the cause of the exception:
Use the Ladebug commands catch and ignore to control whether Ladebug displays and handles exceptions (catches them), or ignores exceptions so that they are handled by the Fortran run-time library.
To obtain the appropriate Fortran run-time error message when debugging a program that generates an exception, you may need to use the appropriate ignore command before running the program. For instance, use the following command to tell Ladebug to ignore floating-point exceptions and pass them through to the Fortran run-time library:
(ladebug) ignore fpe |
Because the where command works only if
the debugger is catching the signal, the ignore command prevents the where command from working. You may want to use
the where command when an exception
occurs to locate the part of the program causing the error. You need to
consider this factor when you use the ignore command.
6.8 Debugging Optimized Programs
The Fortran compiler performs code optimizations (-O4) by default unless you specify -g2 (or -g) . See the DIGITAL Fortran or DIGITAL Fortran 90 user manual for a discussion of compiler optimizations.
Debugging optimized code is recommended only under special circumstances (such as a problem that shows up in an optimized program may disappear when you specify the -O0 flag). Before you attempt to debug optimized code, read Section 6.2.
One aid to debugging optimized code is the -show code flag. This flag generates a listing file that shows the compiled code produced for your program. By referring to a listing of the generated code, you can see exactly how the compiler optimizations affected your code. This lets you determine the debugging commands you need in order to isolate the problem.
Another aid is a set of messages displayed by Ladebug when you try to perform a Ladebug operation on a language construct that has been optimized. For example, if the Fortran compiler can determine that an entire Fortran 90 statement is not needed for correct operation of the program (such as an unnecessary CONTINUE statement), that statement is not represented in the object code. As a result, Ladebug will use the next available line.
For more information on optimizations, see the DIGITAL Fortran or DIGITAL Fortran 90 user manual.
7.1 Significant Supported Features
You can use Ladebug to debug Ada programs on the Tru64 UNIX
operating system. Supported features include the following:
Some of these features are further discussed in this chapter. The
chapter also explains Ada compiler options, debugging limitations, and
specific debugging tasks.
7.2 Compiling and Linking for Debugging
To compile units for debugging, specify the -g compiler option on the ada command, as follows:
% ada -g reservations_.ada reservations.ada hotel.ada |
The -g option automatically suppresses code optimization. Nonoptimized code is easier to debug (although it is possible to debug optimized code). Nonoptimized code more closely resembles your program as you wrote it.
Alternatively, if your program has been compiled once and then modified, you can recompile the program by entering the amake command, as follows:
% amake -C' -g' hotel |
To link units for debugging, enter the ald command, as follows:
% ald -o hotel hotel |
The ald command automatically copies debugging information into the executable file.
For information the amake and ald commands, see manpages amake(1) and ald(1).
7.3 Debugging Mixed-Language Programs
The debugger allows you to debug mixed-language programs. Program flow of control across functions written in different languages is transparent.
The debugger automatically identifies the language of the current function or code segment based on information embedded in the executable file. If program execution is suspended in an Ada function, the current language is Ada. If the program executes a C function, the current language becomes C.
The current language determines the valid expression syntax for the debugger. It also affects the semantics used to evaluate an expression.
The debugger sets the $lang variable to the language of the current function or code segment. By manually setting the debugger variable $lang, you can force the debugger to interpret expresssions used in commands by the rules and semantics of a particular language.
C language syntax is used when $lang is set to Ada; and no thread-related commands are available. |
When the $lang debugger variable is set to Ada, command names and program identifiers are case-insensitive.
The $lang variable is set to "Ada" at Ladebug startup if your program has been linked using the ald linker. In this case, the main routine appears in a pseudo-file with a file name of the following form:
ald_mmmmmmmm_nnnnnnnnnn.ada |
Otherwise, $lang reflects the the
language of the main routine. When the $lang debugger variable is set to a language
other than Ada (which may occur if most, but not all, of your routines
are written in languages other than Ada), command names and program
identifiers follow the case conventions of the $lang setting.
7.5 Printing ISO Latin-1 Characters
The $ascii debugger variable allows you to print ASCII characters in the 7-bit ASCII character set or in the 8-bit Latin-1 character set (a superset of the 7-bit ASCII character set). The ISO Latin-1 standard calls for character representation in 8 bits (256 values), rather than 7 bits, so the extended character set can include additional characters, such as those commonly found in Western European languages. (This character set is not coextensive with the DEC Multinational Character Set, but is very similar.)
To choose a character set, define $ascii as follows:
The Ada CHARACTER data type can contain any of the Latin-1 characters.
7.6 Displaying the Source Code of Generic Units
The instantiation of a generic unit is the code corresponding to the generic unit itself. Ladebug displays the correct source code for the instantiation of a generic unit by recognizing the unique, argumented file names that the DEC Ada compiler records for generic units. For example:
generic -- declaration of generic unit
type T is range <>; --
procedure init (X: out T); -- formal parameter within declaration
procedure init (X: out T) is
begin
X := 0;
end;
with init;
procedure test is
procedure int_init is new init(integer);
-- Ada instantiation of generic unit
I: integer;
begin
int_init(I);
end;
|
In this example, when you step into int_init, you will see the source code that corresponds to the generic procedure init:
X := 0; |
You will not see source code corresponding to the procedure call:
int_init(I); |
In Ada, unlike some other languages, the basic compilation unit need not correspond to a source file. For example:
generic -- first compilation unit in file type T is range <>; -- procedure init (X: out T); -- procedure init (X: out T) is -- second compilation unit in file begin -- X := 0; -- end; -- with init; procedure test is -- third compilation unit in file procedure int_init is new init(integer); I: integer; -- begin -- int_init(I); -- end; -- |
In earlier versions of Ladebug, each compilation unit yielded a separate object file and debug symbol table, while referring to the same source file. However, new naming conventions now provide for the renaming of the source files for better correlation with object files and debug symbol tables, as follows:
You can expect to see these augmented file names when you enter commands that result in file-name output (for example, file, whereis, where ). This naming convention is a temporary solution and may change in future releases.
| Previous | Next | Contents | Index |