HP OpenVMS Systems Documentation

Modules for package bodies are not automatically set by the debugger.

You may need to set the modules for library package bodies yourself so that you can debug the package body or debug subprograms declared in the corresponding package specification.

C.2.15 Resolving Overloaded Names and Symbols

When you encounter overloaded names and symbols, the debugger issues a message like the following:

%DEBUG-E-NOTUNQOVR, symbol 'ADD' is overloaded
     use SHOW SYMBOL to find the unique symbol names

If the overloaded symbol is an enumeration literal, you can use qualified expressions to resolve the overloadings.

If the overloaded symbol represents a subprogram or task accept statement, you can use the unique name generated by the compiler for the debugger. The compiler always generates unique names for subprograms declared in library package specifications, because the names might later be overloaded in the package body. Unique names are generated for task accept statements and subprograms declared in other places only if the task accept statements or subprograms are actually overloaded.

Overloaded task accept statement names and subprogram names are distinguished by a suffix consisting of two underscores followed by an integer that uniquely identifies the given symbol. You must use the unique naming notation in debugger commands to uniquely specify a subprogram whose name is overloaded. However, if there is no ambiguity, you do not need to use the unique name, even though one was generated.

C.2.16 CALL Command

With Ada programs, you can use the CALL command reliably only with a subprogram that has been exported. An exported subprogram must be a library subprogram or must be declared in the outermost declarative part of a library package.

The CALL command does not check whether or not the subprogram can be exported, nor does it check the parameter-passing mechanisms that you specify. Note that you cannot use the CALL command to modify the value of a parameter.

A CALL command may result in a deadlock if it is entered when the Ada run-time library is executing. The run-time library routines acquire and release internal locks that allow the routines to operate in a tasking environment. Deadlock can result if a subprogram called from the CALL command requires a resource that has been locked by an executing run-time library routine. To avoid this situation in a nontasking program, enter the CALL command immediately before or after an Ada statement has been executed. However, this approach is not sufficient to assure that deadlock will not occur in a tasking program, as some other task may be executing a run-time library routine at the time of the call. If you must use the CALL command in a tasking program, you can avoid deadlock if the called subprogram does not do any tasking or input-output operations.

C.3 BASIC

The following subtopics describe debugger support for BASIC.

C.3.1 Operators in Language Expressions

Supported BASIC operators in language expressions include:

Supported constructs in language and address expressions for BASIC follow:

C.3.3 Data Types

If you make changes to a program in the BASIC environment and attempt to compile the program with the /DEBUG qualifier without first saving or replacing the program, BASIC signals the error "Unsaved changes, no source line debugging available." To avoid this problem, save or replace the program, and then recompile the program with the /DEBUG qualifier.

C.3.5 Constants

BASIC constants of the form [radix]"numeric-string"[type] (such as "12.34"GFLOAT) or the form n% (such as 25% for integer 25) are not supported in debugger expressions.

C.3.6 Evaluating Expressions

Expressions that overflow in the BASIC language do not necessarily overflow when evaluated by the debugger. The debugger tries to compute a numerically correct result, even when the BASIC rules call for overflows. This difference is particularly likely to affect DECIMAL computations.

C.3.7 Line Numbers

The sequential line numbers that you refer to in a debugging session and that are displayed in a source code display are those generated by the compiler. When a BASIC program includes or appends code from another file, the included lines of code are also numbered in sequence by the compiler.

C.3.8 Stepping into Routines

The STEP/INTO command is useful for examining external functions. However, if you use this command to stop execution at an internal subroutine or a DEF, the debugger initially steps into run-time library (RTL) routines, providing you with no useful information. In the following example, execution is paused at line 8, at a call to Print_routine:

    ...
->  8  GOSUB Print_routine
    9  STOP
    ...
   20  Print_routine:
   21    IF Competition = Done
   22      THEN PRINT "The winning ticket is #";Winning_ticket
   23      ELSE PRINT "The game goes on."
   24    END IF
   25  RETURN

A STEP/INTO command would cause the debugger to step into the relevant RTL code and would inform you that no source lines are available for display. On the other hand, a STEP command alone would cause the debugger to proceed directly to source line 9, past the call to Print_routine. To examine the source code of subroutines or DEF functions, set a breakpoint on the routine label (for example, enter the SET BREAK PRINT_ROUTINE command). You can then suspend execution exactly at the start of the routine (line 20, in this example) and then step directly into the code.

C.3.9 Symbolic References

All variable and label names within a single BASIC program must be unique. Otherwise the debugger cannot resolve the symbol ambiguity.

C.3.10 Watchpoints

In BASIC, you can set a watchpoint only on variables that are declared in COMMON or MAP statements (static variables). You cannot set watchpoints on variables explicitly declared with the DECLARE statement.

C.4 BLISS

The following subtopics describe debugger support for BLISS.

C.4.1 Operators in Language Expressions

Supported BLISS operators in language expressions include:

Supported constructs in language and address expressions for BLISS follow:

C.4.3 Data Types

The following subtopics describe debugger support for C.

C.5.1 Operators in Language Expressions

Supported C operators in language expressions include:

Because the exclamation point (!) is an operator in C, it cannot be used as the comment delimiter. When the language is set to C, the debugger instead accepts /* as the comment delimiter. The comment continues to the end of the current line. (A matching */ is neither needed nor recognized.) To permit debugger log files to be used as debugger input, the debugger still recognizes an exclamation point (!) as a comment delimiter if it is the first nonspace character on a line.

The debugger accepts the prefix asterisk (*) as an indirection operator in both C language expressions and debugger address expressions. In address expressions, prefix "*" is synonymous to prefix "." or "@" when the language is set to C.

The debugger does not support any of the assignment operators in C (or any other language) in order to prevent unintended modifications to the program being debugged. Hence such operators as =, +=, -=, ++, and -- are not recognized. To alter the contents of a memory location, you must use an explicit DEPOSIT command.

C.5.2 Constructs in Language and Address Expressions

Supported constructs in language and address expressions for C follow:

C.5.3 Data Types

Floating-point numbers of type float may be represented by F_Floating or IEEE S_Floating, depending on compiler switches.

Floating-point numbers of type double may be represented by IEEE T_Floating, D_Floating, or G_Floating, depending on compiler switches.