[Next] [Previous] [Up] [Top] [Contents] [Index]
Chapter 16: Software Development
FLINT is a FORTRAN source code analyzer, a proprietary product of IPT. At Fermilab, FLINT is available for SunOS 5 and IRIX 5. The FLINT User Manual for UNIX is available on the Web (document number PU0099) and on-line in the file $FLINT_DIR/MANUAL wherever FLINT is installed and setup.
FLINT provides several analysis features:
FLINT reports the following error conditions:
Use the -S (upper case) option to specify an output file name. The default extensions listed below are used. A separate file will be created for each component of the listing according to the additional option shown:
lnt Analysis output
xrf Xref table (-x)
tre Call tree (-t)
stt Statistics (-s)
Use the -L option to create a *.lbt FLINT library, containing all subroutine interface information needed for subsequent call usage tests. This library may be specified as FLINT input in place of the original source.
Use the -B option to create a *.fdb database file, containing all the symbol information needed for subsequent cross reference and call tree analysis. This database file may be specified as FLINT input in place of the original source.
Lowercase options may be combined. Use a double dash to disable an option (e.g., --w); this is useful for disabling a default option.
Uppercase options take parameters (with or without a space between the option and the parameter, depending on the option) and do not combine.
When original source is not available, *.lsh ASCII files may be created to describe calling sequences. The file $FLINT_DIR/unixlib.lsh describes the standard UNIX system calls.
To see the standard analysis warnings for Isajet, enter:
% flint $ISAJET_DIR/isajet.f
To see a calling tree of the Isajet program, without warnings, enter:
% flint -t -Tcondensed --w $ISAJET_DIR/isajet.f
To see an options summary, enter:
% flint "-?"
dbx is a utility for source-level debugging and execution of programs written in C, C++, and FORTRAN. dbx allows you to trace the execution of a specified object file. You can step through a program on a line-by-line basis while you examine the state of the execution environment.
Programs compiled with the -g option of cc (and other compilers) produce an object file. This object file contains symbol table information, including the names of all source files that the compiler translated to create the object file.
dbx also allows you to examine core files via its where command. A core file contains the core image produced when the object file was executed, providing information about the state of the program and the system when the failure occurred. A core file named core is produced by default.
dbx commands can be stored in a start-up .dbxinit file that resides in the current directory or in your home directory. dbx executes these commands just before reading the symbol table.
There are some UNIX tools which provide a more sophisticated interface to dbx. See your local system documentation for information on GUI-based dbx tools. The product ddd (originally an interface for gdb) works as a front end for dbx in its more recent releases. It is currently available at Fermilab as part of the gcc product, but we expect to release it as a separate product soon. See the DDD User's Guide on the Web, document number DS0230.
To invoke dbx, enter the following command:
% dbx [options] [object_file [corefile]]
where object_file is the name of the file you want to debug.
Once dbx is running, you should see the (dbx) prompt. At this point you can start issuing dbx commands.
There are many dbx commands, all described in the man pages. Some of the basic commands are run, where, print, stop, list, cont, and quit:
run [arguments] Begin executing the object file, passing optional command-line arguments. The arguments can include input or output redirection to a named file.
where [n] List all active functions on the stack, or only the top n.
print [expressions] Print the values of one or more comma-separated expressions. To print values of two-dimensional FORTRAN array elements use the format: print array_name[1,2]
stop restriction [if cond] Stop execution if specified restriction is true. Restrictions include (this is a partial list):
at (source line) n
if cond
in (procedure or function) func
cond (condition) is a Boolean expression; if it evaluates to true, then execution is stopped.
list [n1 [,n2]] or list funcList the source text between lines n1 and n2, or on lines surrounding the first statement of func. With no arguments, list the next ten lines.
cont [at n] [sig signal] Continue execution from the point at which it was stopped if no arguments. Resume from source line n or, if a signal name or number is specified, resume process as if it had received the signal.
status [> file] Show active trace, stop, and when commands
delete [n] Remove traces, stops, and whens corresponding to each command number n, given by status. If n is all remove all.
quit Exit dbx.
You may want to start by using dbx to set some break points within your code. To step through your code at the very beginning, you need to stop in the MAIN routine if you are debugging an object file created from FORTRAN source code (stop in main if your source is in C language). For example, you would type:
(dbx) stop in MAIN
Now you can issue the run command to start execution of your object file. You will get the process id and the name of the object file being executed.
(dbx) run
At this point, you may use the list command for the first 10-line listing of the source code:
(dbx) list
Use the stop command to set break-points at various lines or procedures within the object-file:
(dbx) stop at 10 (dbx) stop in sub123 (dbx) stop in sub456 if i == 24
The execution will stop in the example above at line 10, or in subroutine sub123, or in subroutine sub456 when i is equal to 24. To continue execution at any point in your debugging, issue the cont command:
(dbx) cont
To restart your debugging session, issue the rerun command:
(dbx) rerun
To exit dbx, type quit:
(dbx) quit
A user reports that when using dbx object_file core he has found it useful to turn on all but one of the IEEE arithmetic traps, in order to stop execution when the arithmetic fault occurs (instead of continuing with some default action and then reporting that the following IEEE arithmetic flags had been set). He located a spurious division by zero in this manner. The f77 man page for Solaris describes the necessary flag value on the f77 command line: -ftrap=%all,no%inexact. We have not researched this for the other UNIX flavors.
gdb, a GNU product, can do four general types of things to help you debug your programs:
You can use gdb to debug programs written in C or C++.
You can also debug programs written in FORTRAN, although gdb does not yet support entering expressions, printing values, or similar features using FORTRAN syntax. Furthermore, it may be necessary to refer to some variables with a trailing underscore.
See the document Debugging with GDB, document number PU0172.
purify is a commercial product that detects memory corruption and finds memory leaks in your executable programs. purify is currently available on FNALU for Solaris. The command to run it is purify.
See the man pages for information on its syntax, options and uses.
CASEVision is an advanced debugging environment for SGI. It is currently available on both of the SGI interactive nodes on FNALU. The command to run CASEVision is cvd.
See the man pages for more information. Additionally, documentation is available through the SGI on-line documentation tool insight (see section 3.1.3).