HP OpenVMS Systems Documentation |
OpenVMS Debugger Manual
8.3 Entering Commands at the PromptThe debugger's Compaq DECwindows Motif for OpenVMS GUI is layered on the command interface. The command line, the last line in the command view and identified by the command-entry prompt (DBG„), lets you enter debugger commands for the following purposes:
Figure 8-9 shows the RUN command in the command view. Figure 8-9 Entering Commands at the Prompt When you use the Compaq DECwindows Motif for OpenVMS interface pull-down menus and push buttons, the debugger translates your input into debugger commands and echoes these commands on the command line so that you have a record of your commands. Echoed commands are visually indistinguishable from commands that you enter explicitly on the command line. For information about the debugger's command interface, see Part 2. For online help about the commands, see Section 8.4.3. In addition to entering debugger commands interactively at the prompt, you can also place them in debugger initialization files and command files for execution within the Compaq DECwindows Motif for OpenVMS environment. You can also take advantage of the keypad support available at the command-entry prompt. (This support is a subset of the more extensive keypad support provided for the command interface, which is described in Appendix A.) The commands in Table 8-6 are mapped to individual keys on your computer keypad.
To enter one of these commands, press the key or keys indicated, followed by the Enter key on the keypad. (The GOLD key is PF1; the BLUE key is PF4.)
For information on changing these key bindings, or binding commands to
unassigned keys on the keypad, see Section 10.10.4.4.
Table 8-7 lists the debugger commands that are disabled in the debugger's Compaq DECwindows Motif for OpenVMS interface. Many of them are relevant only to the debugger's screen mode.
1Help on commands is available from the Help menu in a debugger window.
The debugger issues an error message if you enter any of these commands
on the command line, or if the debugger encounters one of these
commands while executing a command procedure.
The following types of online help about the debugger and debugging are available during a debugging session:
Task-oriented topics related to context-sensitive topics are connected
through the list of additional topics in the help windows.
Context-sensitive help is information about an area or object in a window or a dialog box. To display context-sensitive help:
To display context-sensitive help for a dialog box, you can also click on the Help button in the dialog box.
8.4.2 Displaying the Overview Help Topic and SubtopicThe Overview help topic (Overview of the Debugger) and its subtopics provide task-oriented information about the debugger and debugging. To display the Overview topic, use either of these techniques:
To display information about a particular topic, choose it from the
list of additional topics.
To display help on debugger commands:
Note that the Help command is not available through the command line
interface in the command view.
Debugger diagnostic messages are displayed in the command view. To display help on a particular message:
Chapter 9
|
$ DEBUG/KEEP |
Figure 9-1 Debugger at Startup
Figure 9-2 Running a Program by Specifying an Image
$X1 :== RUN MYDISK:[MYDIR.MYSUBDIR]EIGHTQUEENS.EXE |
Figure 9-3 Running a Program by Specifying a Command Symbol
Once the debugger has control of the program, the debugger:
Figure 9-4 Source Display at Startup
The message displayed in the command view indicates that this debugging session is initialized for a C program and that the name of the source module is EIGHTQUEENS.
With certain programs, the debugger sets a temporary breakpoint to suspend program execution at the start of some initialization code, before the main program, and displays the following message:
Type GO to reach MAIN program No source line for address: nnnnnnnn |
With some of these programs (for example, Ada programs), the breakpoint enables you to debug the initialization code using full symbolic information. The initialization sets up language-dependent debugger parameters. These parameters control the way the debugger parses names and expressions, formats debugger output, and so on.
You can now debug your program as explained in Chapter 10.
Note the following restrictions about running a program under debugger control:
If you try to run a program that does not exist, or misspell the name of a program that does exist, the following error messages are displayed in the DECterm window, rather than in the command view:
%DCL-W-ACTIMAGE, error activating image -CLI-E-IMAGEFNF, image file not found |
When your program completes execution normally during a debugging session, the debugger issues the following message:
'Normal successful completion' |
You then have the following options:
When running the kept debugger (see Section 9.1), you can rerun the program currently under debugger control at any time during a debugging session.
To rerun the program:
Figure 9-5 Rerunning the Same Program
When you rerun a program, it is in the same initial state as a program that is brought under debugger control as explained in Section 9.1, except for any saved breakpoints, tracepoints, or static watchpoints. The source display and current location pointer are updated accordingly.
When you rerun a program, the debugger uses the same version of the
image that is currently under debugger control. To debug a different
version of that program (or a different program) from the same
debugging session, choose Run Image... or Run Foreign Command.. from
the File menu on the main window (see Section 9.1).
9.4 Running Another Program from the Current Debugging Session
You can bring another program under debugger control at any time during
a debugging session, if you started the debugger as explained in
Section 9.1. Follow the procedure in that section for bringing a
program under debugger control (also note the restrictions about using
that procedure).
9.5 Interrupting Program Execution and Aborting Debugger Operations
To interrupt program execution during a debugging session, click on the Stop button on the push button view (see Figure 8-3). This is useful if, for example, the program is in an infinite loop.
To abort a debugger operation in progress, click on Stop. This is useful if, for example, the debugger is displaying a long stream of data.
Clicking on Stop does not end the debugging session. Clicking on Stop
has no effect when the program is not running or when the debugger is
not executing a command.
9.6 Ending a Debugging Session
To end a debugging session and terminate the debugger, choose Exit Debugger from the File menu on the main window, or enter EXIT at the prompt (to avoid confirmation dialogue). This returns control to system level.
To rerun your program from the current debugging session, see Section 9.3.
To run another program from the current debugging session, see
Section 9.4.
9.7 Additional Options for Starting the Debugger
In addition to the startup procedure described in Section 9.1, the following options are available for starting the debugger from DCL level ($):
In all cases, before starting the debugger, verify that you have
compiled and linked the modules of your program (as explained in
Section 1.2).
9.7.1 Starting the Debugger by Running a Program
You can start the debugger and also bring your program under debugger control in one step by entering the DCL command RUN filespec (assuming the program was compiled and linked with the /DEBUG qualifier).
However, you cannot then use the Rerun or Run features explained in Section 9.3 and Section 9.4, respectively. To rerun the same program or run a new program under debugger control, you must first exit the debugger and start it again.
To start the debugger by running a program, enter the DCL command RUN filespec to start the debugger. For example:
$ RUN EIGHTQUEENS |
By default, the debugger starts up as shown in Figure 9-4, executing any user-defined initialization file and displaying the program's source code in the main window. The current-location pointer shows that execution is paused at the start of the main program. The debugger sets the language-dependent parameters to the source language of the main program unit.
For more information about debugger startup, see Section 9.1.
9.7.2 Starting the Debugger After Interrupting a Running Program
You can bring a program that is executing freely under debugger
control. This is useful if you suspect that the program might be in an
infinite loop or if you see erroneous output.
To bring your program under debugger control:
For example:
$ RUN/NODEBUG EIGHTQUEENS . . . [Ctrl/Y] Interrupt $ DEBUG [starts debugger] |
At startup, the debugger displays the main window and executes any user-defined initialization file, and sets the language-dependent parameters to the source language of the module in which execution was interrupted.
To help you determine where execution was interrupted:
When you start the debugger in this manner, you cannot then use the Rerun or Run features explained in Section 9.3 and Section 9.4, respectively. To rerun the same program or run a new program under debugger control, you must first exit the debugger and start it again.
For more information about debugger startup, see Section 9.1.
9.7.3 Overriding the Debugger's Default Interface
By default, if your workstation is running Compaq DECwindows Motif for OpenVMS, the debugger starts up in the Compaq DECwindows Motif for OpenVMS user interface, which is displayed on the workstation specified by the Compaq DECwindows Motif for OpenVMS applicationwide logical name DECW$DISPLAY.
This section explains how to override the debugger's default DECwindows Motif user interface to achieve the following:
The logical name DBG$DECW$DISPLAY enables you to override the default interface of the debugger. In most cases, there is no need to define DBG$DECW$DISPLAY because the default is appropriate.
Section 9.7.3.4 provides more information about the logical names DBG$DECW$DISPLAY and DECW$DISPLAY.
Previous | Next | Contents | Index |