TOC PREV NEXT INDEX DOC LIST MASTER INDEX




User Procedure/Function Calls

For Ada:

It is possible in the debugger to call a procedure that is part of the program being debugged. This is referred to as "user procedure calling".

The debugger treats user procedure calling as an expression and the Execution > Call Subprogram command in any Debugger Window, the Debug:Call Subprogram command in an Editor window, or the p command in the Source or Command Line Pane implements this capability. For example, to call the procedure Dump, enter the following on the command line or select Execution > Call Subprogram from any Debugger Window:

With user procedure calling, build customized displays for key objects and access data structure routines. Write routines to display data structures, to verify that data structures have certain properties (for example, is the table sorted?) or to display and navigate through a complex data structure. Then, access these routines in the debugger.

A procedure called by the debugger is not limited to displaying numbers and text on the screen. The procedure can prompt for input, read it and act on it interactively. Display output from the procedure or capture it in the debugger log file.

Since these procedures are written in Ada as part of the user program, they can be called from the program, e.g., a procedure can display data structures when an internal error is detected or prior to a catastrophic failure. If these procedures are left in the program after it is deployed, they provide a method for debugging the program in the field at a customer site.

Currently, calling lexically nested procedures only works if the procedure makes no reference to up-level variables. If you set a breakpoint in a lexically nested procedure, call the procedure, hit the breakpoint and try to examine up-level variables, the debugger is not able to find the address(es) of these variables.

Note that if the procedure call hits a breakpoint, the program stops and the user can debug as normal; however, the debugger abandons evaluating the expression, if any. For example:

Case 1: The user calls cos() and has no breakpoints set in cos or in any routines that cos() calls. The debugger prints the return value:

Case 2: The user calls cos() and has a breakpoint set in cos():

Note that in this second case, the value is not printed. When the procedure returns from the user-generated call, that is, from the debugger command p cos(45.0), because expression evaluation is interrupted by the breakpoint, the debugger makes no attempt to continue with expression evaluation.

Case 3: The user calls foo(cos(45.0)), where foo is a subprogram and has a breakpoint in cos():

In this third case, the procedure that returned normally is cos, not foo(). foo() is never called because expression evaluation is abandoned during the call to cos() because of the breakpoint.

Subprogram calling is described in detail in Using the Apex Debugger.

For C/C++:

It is possible in the debugger to call a function that is part of the program being debugged. This is referred to as "user function calling".

The debugger treats user procedure calling as an expression and the Execution > Call Subprogram command in any Debugger Window, the Debug > Call Subprogram command in an Editor window, or the p command in the Source or Command Line Pane implements this capability. For example, to call the procedure Dump, enter the following on the command line or select Execution > Call Subprogram from any Debugger Window:

The debugger treats user function calling as an expression and the p command implements this capability. For example, to call the function dump, enter the following:

With user function calling, build customized displays for key objects and access data structure routines. Write routines to display data structures, to verify that data structures have certain properties (for example, is the table sorted?) or to display and navigate through a complex data structure. Then, access these routines in the debugger.

A function called by the debugger is not limited to displaying numbers and text on the screen. The function can prompt for input, read it and act on it interactively. Display output from the procedure or capture it in the debugger log file.

Since these functions are written in C/C++ as part of the user program, they can be called from the program, for example, a function can display data structures when an internal error is detected or prior to a catastrophic failure. If these functions are left in the program after it is deployed, they provide a method for debugging the program in the field at a customer site.

Currently, calling lexically nested functions only works if the function makes no reference to up-level variables. If you set a breakpoint in a lexically nested function, call the function, hit the breakpoint and try to examine up-level variables, the debugger is not able to find the address(es) of these variables.

Case 1: the user calls cos[] and has no breakpoints set in cos or in any routines that cos[] calls. The debugger prints the return value:

Case 2: The user calls cos[] and has a breakpoint set in cos[]:

Note that in this second case, the value is not printed. When the function returns from the user-generated call, i.e., from the debugger command p cos[45.0], because expression evaluation is interrupted by the breakpoint, the debugger makes no attempt to continue with expression evaluation.

Case 3: The user calls foo[cos[45.0]], where foo is a function and has a breakpoint in cos[]:

In this third case, the function that returned normally is cos, not foo[]. foo[] is never called because expression evaluation is abandoned during the call to cos[] because of the breakpoint.

Additional Topics

To see related information, click on a topic:


Rational Software Corporation 
http://www.rational.com
support@rational.com
techpubs@rational.com
Copyright © 1993-2001, Rational Software Corporation. All rights reserved.
TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS