Tru64 UNIX
Ladebug Debugger Manual


Previous Contents Index

5.12 Debugging C++ Exception Handlers

You can debug C++ exception handlers in programs by setting breakpoints in the exception handler or in the predefined C++ functions that are used when exceptions occur. You can also examine and modify variables that are used in exception handlers.

5.12.1 Setting Breakpoints in Exception Handlers

As shown in Example 5-22, you can set a breakpoint for an exception handler at the line number where the code for the exception handler begins. You can then step through the exception handler, examine or modify variables, or continue executing the program. You can also set breakpoints in C++ functions used to handle exceptions as follows:
terminate Gains control when any unhandled exception occurs and terminates the progrm
unexpected Gains control when a function containing an exception specification tries to throw an exception that is not in the exception specification

Example 5-22 Setting Breakpoints in Exception Handlers

(ladebug) list 24
     24     try 
     25     { 
     26          foo(); 
     27     } 
     28     catch(char * str) { printf("Caught %s.\n",str); } 
     29     catch(...) { printf("Caught something.\n"); } 
     30 
     31 return 0; 
     32 } 
(ladebug) stop at 24
[#1: stop at "except.C":26 ] 
(ladebug) stop in unexpected
[#2: stop in unexpected ] 
(ladebug) run
[1] stopped at [int main(void):26 0x400370] 
     26          foo(); 
(ladebug) cont
[2] stopped at [unexpected:631 0x4010a8] 
(Cannot find source file cxx_exc.c) 
(ladebug) cont
In my_unexpected(). 
Caught HELP. 
Thread has finished executing 
(ladebug) 

5.12.2 Examining and Modifying Variables in Exception Handlers

After you set a breakpoint to stop the execution in the exception handler, you can access the variables used in the exception handler the same way you would examine and modify other program variables. See Section 2.6.

5.13 Advanced Program Information: Verbose Mode

By default, the debugger gives no information on virtual base class pointers for the following:

By setting the $verbose debugger variable to 1, you can request that this information be printed in subsequent debugger responses.

When the $verbose debugger variable is set to 1 and you display the contents of a class using the whatis command, several of the class members listed are not in the source code of the original class definition. The following line shows sample output from the whatis command:


array [subrange 0 ... 0 of int] of vtable * __vptr; 

The vtable variable contains the addresses of all virtual functions associated with the class. Several other class members are generated by the compiler for internal use.

The compiler generates additional parameters for nonstatic member functions. When the $verbose debugger variable is set to 1, these extra parameters are displayed as part of each member function's type signature. If you specify a version of an overloaded function by entering its type signature and the variable is set to 1, you must include these parameters. Do not include these parameters if the variable is set to 0.

When the $verbose variable is set to 1, the output of the dump command includes not only standard program variables but also compiler-generated temporary variables.

Example 5-23 prints class information using the whatis command when the $verbose variable is set to 1.

Example 5-23 Printing a Class Description in Verbose Mode

(ladebug) print $verbose
0 
(ladebug) whatis S
class S  { 
  int i; 
  int j; 
  S (void); 
  ~S (void); 
  int foo (void); 
  virtual int bar (void); 
} S 
(ladebug) set $verbose = 1
(ladebug) print $verbose
1 
(ladebug) whatis S
class S  { 
  int i; 
  int j; 
  array [subrange 0 ... 0 of int] of vtbl * __vptr; 
  S (S* const); 
  S (S* const, const S&); 
  ~S (S* const, int); 
  int foo (S* const); 
  S& operator = (S* const, const S&); 
  virtual int bar (S* const); 
} S 
(ladebug) 

When displaying information on classes, the debugger prints a pointer to the table describing the base class for each virtual base class object member. This pointer is known as the virtual base pointer, and is identified as _bptr. This pointer is printed as part of the class member information. More than one _bptr may be displayed with those belonging to base classes being denoted.

5.14 Limitations on Ladebug Support for C++

Ladebug interprets C++ names and expressions using the language rules described in The Annotated C++ Reference Manual (Ellis and Stroustrup, 1990, Addison-Wesley). C++ is a distinct language, rather than a superset of C. Where the semantics of C and C++ differ, Ladebug provides the interpretation appropriate for the language of the program being debugged.

To make Ladebug more useful, it relaxes some standard C++ name visibility rules. For example, you can reference both public and private class members.

The following limitations apply when you debug a C++ program:

Limitations for debugging templates include:


Chapter 6
Debugging DIGITAL Fortran Programs

6.1 Significant Supported Features

You can use Ladebug to debug Fortran programs on the Tru64 UNIX operating system. The following features are supported:

This chapter also discusses flags used with the Fortran compiler commands, 1 Fortran data types in Ladebug, limitations on Ladebug support for Fortran, debugging a Fortran program that generates an exception, and locating unaligned data.

Note

1 f77 is the DIGITAL Fortran compile command, and f90 is the DIGITAL Fortran 90 compile command. In this chapter, Fortran refers to both DIGITAL Fortran and DIGITAL Fortran 90.

6.2 Fortran Flags for Debugging

To prepare to use the Ladebug debugger on a Fortran program, invoke the compiler with the appropriate debugging flag: -g, -g2, or -g3 and, for DIGITAL Fortran 90 only, -ladebug. For example, for DIGITAL Fortran 90:


% f90 -g -ladebug -o squares squares.f90

For DIGITAL Fortran:


% f77 -g -o squares squares.for

This f77 command compiles and links the program squares.for without optimization but with symbol table information needed for symbolic debugging with Ladebug. The executable file is named squares instead of a.out.

The -gn flags control the amount of information placed in the object file for debugging.

For DIGITAL UNIX Version 3.2 systems, Table 6-1 summarizes the information provided by the debugger-related flags and their relationship to the -On flags, which control optimization. Refer to your language compiler documentation for the latest information on compiler flags used on DIGITAL UNIX Version 5.0 systems.

Note

Ladebug cannot distinguish between a Fortran 77 and a Fortran 90 compilation unit because the respective compilers do not make such distinctions. The value of $lang is always "Fortran" in both cases.

Table 6-1 Summary of Symbol Table Flags
Flag Traceback
Information
Debugging Symbol
Table Information
Effect on -On Flags
-g0 No No Default is -O4 (full optimization).
-g1 (default) Yes No Default is -O4 (full optimization).
-g2 or -g 1 Yes Yes. For unoptimized code only. Changes default to -O0 (no optimization).
-g3 Yes Yes. For unoptimized code only. Default is -O4 .
-ladebug (f90 only) Yes Allows access to Fortran-90 dynamic arrays using standard Fortran-90 syntax, including array sections. No effect.


1The -g and -g2 options are equivalent.

Traceback information and symbol table information are both necessary for debugging. They enable the debugger to:

Typical uses of the debugging flags at the various stages of program development are as follows:

Traceback and symbol table information result in a larger object file. When you have finished debugging your program, you can remove traceback information with the the strip command (see strip(1)). To remove symbol table information, you can compile and link again with -g0 or -g1 to create a new executable program.

If your program generates an exception, recompile using the -fpen flag (see Section 6.7).

For more information on program development and run-time environments, see the DIGITAL Fortran or DIGITAL Fortran 90 user manual.

Note

1 -g1 results in a larger object file than -g0 but smaller than the other gn flags

6.3 Displaying Fortran Variables

When the $lang debugger variable is set to Fortran, command names and program identifiers are case insensitive. For more information about the $lang debugger variable, see Section 6.6.

To refer to a variable named J, use either the uppercase letter J or its lowercase equivalent, j.

You can also enter Ladebug command names in uppercase or lowercase. For example, the following two commands are equivalent:


(ladebug) PRINT J


(ladebug) print j

6.3.1 Fortran Common Block Variables

You can display the values of variables in a Fortran common block using Ladebug commands such as print, the Print button or Print dialog box in the GUI, or the whatis command.

To display the entire common block, use the common block name. For example:


(ladebug) list 1,11
      1       PROGRAM EXAMPLE 
      2 
      3       INTEGER*4 INT4 
      4       CHARACTER*1 CHR 
      5       COMMON /COM_STRA/ INT4, CHR 
      6 
      7       CHR = 'L' 
      8 
>     9       PRINT *, INT4, CHR 
     10 
     11       END
(ladebug) print com_stra
COMMON 
    INT4 = 0 
    CHR = "L"
 

To display a specific variable in the common block, use only the field name. For example:


(ladebug) PRINT CHR
"L"

If your program contains a common block and a member of the same name, the common block will be occluded by the member.

6.3.2 Fortran Derived-Type Variables

Variables in a Fortran 90 derived-type (TYPE statement) are represented in Ladebug commands, such as print or whatis, using Fortran 90 syntax form.

For derived-type structures, use:

For example:


(ladebug) list 3,11
      3       TYPE X 
      4       INTEGER A(5) 
      5       END TYPE X 
      6 
      7       TYPE(X) Z 
      8 
      9       Z%A = 1 
     10 
>    11       PRINT*, Z%A
(ladebug) print Z%A
(1) 1 
(2) 1 
(3) 1 
(4) 1 
(5) 1

6.3.3 Fortran Record Variables

Variables in a Fortran record structure (STRUCTURE statement) are represented in a fashion similar to derived-type.

For record structures, use:

For example:


(ladebug) l 3,13
      3       STRUCTURE /STRA/ 
      4          INTEGER*4 INT4 
      5          CHARACTER*1 CHR 
      6       END STRUCTURE 
      7 
      8       RECORD /STRA/ REC 
      9 
     10       REC.CHR = 'L' 
     11       REC.INT4 = 6 
     12 
>    13       PRINT *, REC.CHR, REC.INT4
(ladebug) print rec%int4
6
(ladebug) print rec.int4
6

To view all fields in the record structure, type the name of the record structure, such as rec (instead of rec%int4 or rec.int4 in the previous example).

6.3.4 Fortran Array Variables

For array variables, put subscripts within parentheses, as with Fortran source statements. For example:


(ladebug) assign arrayc(1)=1

You can print out all elements of an array using its name. For example:


(ladebug) print arrayc
 
(1) 1 
(2) 0 
(3) 0

Avoid displaying all elements of a large array. Instead, display specific array elements or array sections. For example, to print array element arrayc(2):


(ladebug) print arrayc(2)
 
(2) 0

6.3.4.1 Array Sections

Fortran provides an array notation known as an array section. Array sections consist of a three parts, a starting element, an ending element, and a stride. Ladebug supports arrays up to 31 dimensions. For more information on arrays, see the DIGITAL Fortran or DIGITAL Fortran 90 user manual.

Consider the following array declarations:


INTEGER, DIMENSION(0:99)    :: arr 
INTEGER, DIMENSION(0:9,0:9)  :: TenByTen 

Assume that each array has been initialized to have the value of the index in each position, for example, TenByTen(5,5) = 55, arr(43) = 43. The following expressions will be accepted by the debugger:


(ladebug) print arr(2)
2
(ladebug) print arr(0:9:2) 
(0) = 0 
(2) = 2 
(4) = 4 
(6) = 6 
(8) = 8
(ladebug) print TenByTen(:,3)
(0,3) = 3 
(1,3) = 13 
(2,3) = 23 
(3,3) = 33 
(4,3) = 43 
(5,3) = 53 
(6,3) = 63 
(7,3) = 73 
(8,3) = 83 
(9,3) = 93

The only operations permissible on array sections are whatis and print.

Ladebug supports the array section notation for both Fortran-90 and Fortran-77 programs.


Previous Next Contents Index