![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Using the Apex Debugger The Apex debugger offers a powerful set of features to help you find bugs and analyze your program's behavior. It supports source level debugging for Ada, C, and C++, including programs comprising mixtures of these languages.
Note: Support for these languages is dependent on the variant of Apex (Apex Ada, Apex C/C++, or Apex Duo) you have. Apex Duo supports all Ada and C/C++ debugging capabilities described in this manual.
This chapter provides an overview of debugger capabilities and interfaces. The following sections are included in this chapter:
OverviewThe debugger operates either at the source level or at the machine level. In source level debugging, you deal with your program's source as it was compiled. You can set breakpoints at source line numbers, statements, or declarations. When you print out variables, the values are displayed in a format appropriate to their declared type. You can also define your own custom display methods that the debugger will use for objects of the specified types.
In machine mode, the debugger displays the source disassembled into the machine instructions generated by the compiler. You can dump or modify memory in a variety of formats —— decimal, hexadecimal, octal, and binary. The debugger lets you display and modify machine registers. You can set breakpoints on or single step through individual instructions. Machine level debugging is discussed in detail in Machine Level Debugging
You can control the execution of your program through commands that place breakpoints and continue execution. The breakpoints can have conditions and actions associated with them. You can step through your program at both the source and machine level, stepping either into or over Ada subprograms or C/C++ functions at either level. You can also invoke Ada subprograms or C/C++ functions in your program directly from the debugger. Debugger execution is described in Controlling Execution.
The debugger lets you control the language exceptions and UNIX signals while your program is executing. You can stop execution at specified signals or exceptions or let them be automatically propagated to your program. Exceptions are described in Handling Exceptions
The debugger has several interfaces. There is an easy-to-use Graphical User Interface that provides menu-driven access to the debugger's facilities. The debugger GUI is described in The Debugger's GUI. The GUI debugger also contains a powerful command language that provides short-cuts to commands. This command language is also accessible through a non-GUI, text-based interface. An overview of this interface is provided in The Debugger's Command-Line Interface.
The debugger has many other features. An easy way to become familiar with the Apex debugger is to work through the Using the Debugger"exercise in the Online Tutorial. The exercise can provide you with some valuable hands-on experience in using the debugger. If you are not familiar with the Apex debugger, it is recommended that you work through this exercise before you read this chapter. For a less complex exercise in using the debugger, a quick tutorial is provided in Getting Started with the Debugger.
The Debugger's GUIA special graphical user interface is provided with the Apex debugger. This section provides a brief introduction to this interface.
Debugger Modes
The Apex debugger can be configured to behave in one of two modes for the display of source code: either through one of the editors or through its own source pane in the debugger window. You can configure the default source display method that's used when the debugger starts up. You can also toggle between them during a debugging session.
Using an Apex editor to display source allows you to retain the full capabilities of the editor while you're debugging. For example, you can perform Summit/CM operations, compilation, or editing operations during a debugging session.This display mode is called editor mode. It is the default.
The debugger's source display is optimized for debugging. It doesn't provide facilities for editing, compilation, or source control, for example. It does provide extra features specifically designed for debugging. For example, it contains source indicators that show where breakpoints are set. This mode is called Show Source mode.
There are several ways to configure the debugger mode:
- Set the X resource Rational.Debugger.log*debugSource: to True. This will cause the debugger to operate in Show Source mode by default.
- Set the display mode using the View > Show Source command. Once the Source Pane is displayed, save the display mode using the Tools > Session > Save Window Properties. Source mode now becomes your default display mode.
Once you are in the debugger, you can easily switch modes using the View > Show Source command which toggles between the two modes.
The Visit Editor button displays the currently visible source in the language editor if you are in Show Source mode.
If an external editor is being used, when source code is automatically displayed, the debugger replaces the editor window with another editor window containing the current Ada unit or C/C++ file. This means if the debugger has displayed a Ada unit or C/C++ file, the debugger will replace that Ada unit or C/C++ file when another becomes the current Ada unit or C/C++ file. If you want to keep the original editor window containing a particular Ada unit or C/C++ file, choose the Debug > Keep command in the editor window.
Debugger Windows
There are several ways to open the Debugger window illustrated in Figure 1. One way is to follow these steps:
- 1 . Open an editor window.
- 2 . Choose the Window command from the Debug menu. The window illustrated in Figure 1 is displayed.
- 3 . From that submenu, choose the Main Window command.
Figure 1 Debugger Window.
![]()
The Debugger Log window is the main Apex debugger window. When you conduct a debugging session, all interactions with the debugger are displayed in a sequential log in this Debugger window.
The section below the log window is called the Command Pane. This area can be used to enter debugger commands through the keyboard. These commands are listed in "List of All Commands" on page 24.
It is also possible to display information about the current program being debugged in a status line at the bottom of the Debugger Window. To display the Status Pane, select the View > Show Status Pane command. A new area will appear at the bottom of the window containing the following information about the current program:
state stop_frametask_id_number
file_name
An additional window is also available for display within the main Debugger window. This window is called the Source pane and is illustrated in Figure 2.
Figure 2 Debugger Source Window
![]()
The Source pane is used to display program source text. Use of this window allows you to do all your debugger operations within the Debugger Window, without using an external editor.
This program source can either be in regular source mode or in disassembly mode. Source mode is the default. In disassembly mode, the source window contains disassembled machine instructions, interspersed with source code, if available. Toggle between source and assembly mode by selecting the Disassembly button on the Toolbar or by positioning your cursor in the source window and entering I (capital I).
To toggle the display of the Source, Status, and Command Panes from within the debugger, use the View menu selections View > Show Source, View > Show Status and View > Show Command Pane. If you are in Show Source mode, you can toggle into editor mode by deselecting the View > Show Source command. You can also display the editor window using either the Visit Editor button or the Navigate > Visit Editor command.
Other Debugger Windows
You can also open several other kinds of debugger windows from the Debug > Window submenu. They are listed and described in Table 1.
Each of these windows is discussed in more detail in both the online reference and in the sections of this manual that discuss the topics the window is associated with.
Help!
An extensive online help facility is available with the GUI debugger. To access this help facility, use the Help > On Context command. When you select this command, the cursor becomes a question mark. Place the question mark on any menu item or button you wish to find out about and click. The online reference information for that entry will be displayed. In addition, an online tutorial is available by selecting the Help > Tutorial command. You can also access any other Apex document by selecting the Help > Manuals command.
Entering help in the Command Pane will provide access to this document.
The Debugger's Command-Line InterfaceNormally the debugger is invoked through the Apex File > Run or File > Debug command. It is, however, possible to invoke the debugger directly, without the GUI. Do this by using the rdb command.
If the rdb command is used, the debugger can be run in either line-mode or screen-mode. Line-mode is a more traditional interface. The screen-mode interface provides a more convenient interface for most people. Every function available in line-mode is also available in screen-mode. Screen mode is described in detail in Screen Mode Operation,
Invocation
rdb is a symbolic debugger for Ada and C/C++ programs, compiled with the -g option.
Note: For Sun Solaris C/C++, the -xs option is also required. For example,
cc -g -xs hello.c -- Sun Solaris
For Native systems, invocation options to the program being debugged can be specified at debugger invocation. All command line options that follow the name of the executable are assumed to belong to the program being debugged.
The -r option provides a means to disambiguate options to the debugger and options to the executable file as they are interpreted by the shell on subsequent invocations of the debugger. The -r option initializes set run shell_arguments to a string made up of the executable_file and the executable_file_options enclosed in quotes. Enclosing shell commands that pertain to the executable file within the quotes, (output redirection for example) assures that they are not interpreted by the shell to apply to the debugger itself.
Any single unit or token on the command line can be up to 511 characters long.
If an argument string in the invocation of the program being debugged contains shell wildcards, it is expanded by the shell. If this expansion fails because there is no matching file, the original unexpanded argument string is passed to the program. This invocation is consistent with the Bourne shell and C shell when nonomatch is set.
Error output from globbing is checked for. If there is error output, a diagnostic is displayed as well as the argument that caused it. The original string is then passed to the program as the argument. This is also consistent with nonomatch set in the Bourne and the C shells.
Detailed descriptions of interactive rdb commands are provided in this manual, which is also available online.
Use the quit command to leave the debugger and return to the shell.
Syntax
rdb [rdb_options]
[executable_file
[executable_file_options
]]Arguments
- rdb_options
Options to the debugger. These are:
Invoke the debugger on the currently executing process (PID). The debugger does not join the process group of that process. Use the ps or jobs command to get the PID.
Debug the core file indicated by core_file_name. If no core file name is included, a core file is searched for in the current directory.
Debug C programs. This option avoids error messages relating to missing Ada libraries.
(entry) Specify the program entry point. This option starts a program at an address different than the default starting address.
(input) Read input from the specified file. Unless one of the commands in the specified file is quit, the debugger will switch to standard input when the commands in the file are exhausted.
(log) Log debugger and program output to the named file. See also set log [off|filename].
(link) For Ada, read program compilation information from the specified view, rather than the current directory, as though you are operating in the specified view. This allows the debugger of executables that have been moved from their original link view. When copying executables, care should be taken to preserve the timestamp of the executable (for example, with the UNIX cp -p command). This allows the debugger to correctly display a warning when the source corresponding to the executable is newer than the executable.
If a C or C++ program is debugged outside of its build view, the set source command should be used to specify the build view pathname.
Avoid loading the program onto the target machine. Instead, run the program in place on the host machine. Set the environment variable APEX_LYNX_NFS to always have this affect on apex_debug executions.
Note: The target machine must have visibility to the directory on the host machine where the program is. This option is for Apex for Lynx only.
-p program_io_file
-pi program_input_file
-po program_output_file(program) Redirect program input and/output to the named file. See also the set input [pty|tty||filename] and set output [pty|tty||filename] debugger commands.
-program_file configuration_file_name
(multi-program) Debug multiple executables. See Debugging Multiple Programs.
-r "executable_file [executable_file_options]"
(run) Initialize set run shell_arguments with executable_file and executable_file_options.
(sync) Do not perform an automatic download when the debugger is invoked. (Apex embedded only)
(show) Display the name of the debugger executable but do not execute. This option is useful if multiple versions of Apex are on a system.
(terminal) Read terminal state from filename.
When the debugger runs in the background, it cannot reliably get the state of the controlling terminal, as that state changes as you run other programs in the foreground. But the output of the program being debugged depends on the set up of your terminal. tty_state must be run in the foreground and it dumps the terminal state to a file. Invoke this program as follows:
tty_state -ffilename
-w
Then supply that same filename to the debugger with the -t option. Note that you can print the tty state that is written to filename by typing:
tty_state -ffilename
-r
executable_file Name of file to execute and debug. If executable_file is not specified, the debugger searches for the default. If only a root filename is given (foo, as opposed to /vc/sbq/foo), the debugger searches the directories on the PATH environment (exported) variable for an executable file foo just as the shell does. Note that if "." is not on your Adapath (Ada) or search path (C/C++), you must enter rdb ./foo.
executable_file_options Command line options that pertain to the executable_file being debugged. All command line options that follow the name of the executable are assumed to belong to the program being debugged.
Invocation File
In addition to the invocation line, you can supply parameters to rdb using an invocation file. These are discussed under the state command. Debugger state files are also know as "dbrc" files, as they have a .dbrc extension.
An invocation file can contain any arbitrary debugger command. The invocation files are read in just before the debugger issues its first prompt (actually, right before any -i specified input file, which happens before the first prompt).
Start-up Environment
The debugger establishes the debugging environment when it starts up. The screen displays certain key parameters to verify what and where it is debugging.
Redirecting Debugger Input and Output
Normally the debugger reads from the terminal. By using the following redirection options to rdb, redirect standard input, standard output and standard error to a file.
< filename Direct input to the debugger from filename
> filename Direct output from the debugger to filename.
>& filename Direct debugger output and error messages to filename.
Syntax of Debugger Commands
Most debugger commands are of the form: keyword parameters.
In line mode, debugger keywords are not case sensitive. For example b 357, set breakpoint at line 357 can be entered also as B 357. However, certain identifiers, pathnames and C variables for example, are case sensitive.
In screen mode, due to several special cases, debugger keywords are case sensitive. For example:
In line mode, enter a list of commands on a single line separated by semicolons (except commands with parameters that the shell interprets). In screen mode, precede a list of commands with a colon.
Line-mode commands execute when Return is pressed. The single exception is a breakpoint command followed by a block of commands as illustrated here. The breakpoint is set after the final Return after the end keyword.
> b 200 begin ?? p subprogram() ?? p variable : g : end
The debugger uses your language syntax for comments: characters between the double dash (--) (Ada) or double slash (//) (C/C++) and Return are ignored.
While in line mode, RETURN repeats the most recent of several commands (o, oi, i, ii, s, si, l,li, / ?). Debugging a program with an r (run) or g (go) command clears RETURN until one of the repeatable commands is used again. Each command that repeats in this way is marked in the documentation with the phrase `RETURN repeats.' In screen mode, repeat the previous command line with a period.
In screen mode, you can protect yourself from accidentally restarting the program by setting the debugger safe parameter to on (set safe on). When this parameter is set, any letter which will restart the program must be typed twice. For example, rr must be entered to rerun the program and ss to single step.
You can enter a number as either decimal or hexadecimal. If the leading digit of a number is a zero, the debugger assumes it is a hexadecimal number (0123 or 0F2).
When a name can be either a debugger keyword or a variable name, the debugger interprets it as a keyword. Precede the name with a backslash (\) to force the debugger to interpret it as a variable.
Frequently, the documentation for the debugger refers to the Interrupt key (Intr). The system command stty allows this function to be assigned to any convenient key (often Control-C). The Interrupt key halts the program being debugged if it is running, or the debugger's current operation. The debugger responds immediately to the Interrupt key with a prompt for the next command.
Control characters (for example, Control-Z) have their usual meaning.
Line Editing/Command History
The debugger supports line editing functions that enable the user to make simple changes to a command before transmitting it to the debugger. In addition, the debugger supports a command history mechanism that recalls a previous command for editing and execution.
The best way to learn about the line editing and command history features of the debugger is to try them. We recommend getting into a debugging session and typing a few commands. Then try out the features described in the following sections.
Line editing and command history only apply to debugger commands entered in the non-GUI debugger (or the Command Pane of the debugger GUI). Window control commands and debugger commands that are entered directly in screen mode cannot be line edited and are not saved in the history buffer.
Command History
When you transmit a command to the debugger by typing Return, the debugger remembers it (unless it is exactly the same as the previous command). The debugger has a 2048 character circular buffer to save the most recent Command Line Pane commands. Since debugger commands are typically under 10 characters, this buffer holds about 200 of the most recent commands.
Two line editing commands are specific to command history:
k Go backwards in history one command.
j Go forward in history. Only use j after at least one k.
Enter these two commands when line editing a debugger command (but not when in insert mode). Every time you type a k you go back one command. That command is displayed at the current prompt with the cursor at the right of the command. If you then type a Return, the command is submitted to the debugger. Alternatively, use any of the line editing commands to change the command, before typing Return to submit it to the debugger.
Line editing
When you enter a command to the debugger, you are in one of two modes, insert or edit. Normally you are in insert mode with the cursor at the end of the command line. Each character you type is added to the command at the end. The two most common line editing commands used in insert mode are "erase" (usually Control-H) to backspace over the most recent character, and "kill" (typically Control-U) to erase the entire line. The debugger uses the user stty "erase" and "kill" characters to perform these functions. The operating system stty command displays the current erase and kill characters.
To leave insert mode and enter edit mode, the Escape key is used. This moves the cursor back one character, placing it over the last character inserted.
Whether you are in edit or insert mode, whenever you type a Return, the entire line is transmitted to the debugger, even if the cursor is positioned in the middle of the line. In other words, what you see is what is sent to the debugger. Here is a list of the available line editing commands:
The "M" [mode] column
i = Command available in insert mode
b = Command available in both modes
e = Command available in edit modeMotion
Select one of the following characters as a motion character for the CHANGE or DELETE editing functions. The motion character determines what changes.
Additional Notes
- 1 . For the change commands (CHANGE and CHGROL), you enter change mode after typing the command. The change area is marked by a dollar sign ($) on the right end and the cursor on the left end. This entire area is replaced by what you type. If what you type is shorter than the change area, then the remainder of the change area is deleted. If what you type is longer, then the remainder of the line is pushed to the right to make room.
- 2 . The h, j, k and l characters give the directions left, down, up and right respectively. If you view the history as a page of text, then the j key moves up the page and the k key moves down the page.
- 3 . If you type ?p in edit mode, the last command stored in history that has a p in it is matched. Note that the command does not have to start with a p. If no match is found, a beep is sounded. Use the / in edit mode to search forward in history. Note that N and n in edit mode must follow the completion of either a / or a ? command.
- 4 . In addition to ERASE KILL, WERASE and REPRINT are character sequences that the debugger inherits from your current stty settings.
- 5 . The command stringESC= provides the ability to find all names in the current scope that begin with the string entered before the ESC. For example, if you are debugging "Hello World", the following can be entered.
>p p<ESC>= (1) text_io.put_line'2 (string ) (2) text_io.put_line'1 (file_type, string ) (3) text_io.put'4 (string ) (4) text_io.put'3 (file_type, string ) (5) text_io.put'2 (character ) (6) text_io.put'1 (file_type, character ) (7) text_io.positive_count (8) text_io.page_length'2 ( ) return count (9) text_io.page_length'1 (file_type ) return count (10) text_io.page'2 ( ) return positive_count (11) text_io.page'1 (file_type ) return positive_count (12) EXCEPTION.program_error (13) positive >p p
- 6 . An additional feature uses the numbers produced from the stringESC= command to quickly change the command line. The current string is completed to the string listed by the number chosen using the string(#) command. For example, after issuing the p pESC= command, you may wish to continue the p p command with put'4 (number 3 in the list). You can do this by entering the following at the spot where the cursor is located:
Note: Matching is done on the names of the subprograms or variables that are visible, not by the name of the package. In the example above, the list comes from matching the letter p. You would not see the entries in the list that match t for Text_Io if you typed tESC=. The name of the package is printed in the list for your convenience.
Screen Mode Operation
The debugger supports a screen-oriented interface in addition to the more traditional line-oriented interface.
Invocation
To use the screen interface, either invoke the debugger with the -v option,
rdb -v myprogram
or use the vi command from line mode.
To switch from screen mode to line mode, type the screen command Q.
Windows
In screen mode, the debugger divides the screen into three windows. The top window is called the source window. It goes from the top of the screen to the dashed line and is used for program source text. The window below the dashed line is called the command window. It displays command input to the debugger, text input to the program being debugged and debugger/program output. The last line on the screen is called the error window and displays error messages from the screen-mode interface, patterns, etc. Output that appears in the error window does not appear in a log file.
The top two windows display a portion of a potentially larger area. For example, the source window displays part of a source file. Move this window to display a different part of the same source file or display part of a different source file.
The debugger keeps the last 750 lines of text that are displayed in the command window in an internal history buffer. Typically, the command window is positioned to display the most recent interactions (the end of the history buffer). However, this window behaves just like the source window in that you can use window control commands to view previous history.
The command window is paged automatically. If output from either a single debugger command or the user program scrolls off the top of the window, the output stops and --More-- is displayed on the last line. The available responses are listed in the following table.
When the screen interface is invoked, the source window is 2/3 of the available screen size, the error window has 1 line and the command window has the remainder of the screen. Change the size of the source and command window at any time using the C command. The debugger remembers the most recent settings over subsequent Q and vi commands.
Entering Commands
Screen-mode commands are those commands that are processed directly by the screen interface. These commands are not followed by Return —— they execute immediately when the entire command is typed. Precede some screen commands with an optional numeric argument.
Two classes of screen commands exist. The window control commands allow manipulation of the window interface. The immediate debugger commands are recognized by the screen interface and passed directly to the debugge
The window control commands are applied to the window that contains the cursor. The comma (,) command moves the cursor from source window to command window or the reverse.
Instruction and Source Sub-modes
In screen mode, the debugger supports two sub-modes, instruction and source. The I (uppercase i) command toggles the sub-mode, switching from one to the other. In source mode, the source window displays program source code and the s, i, and o commands single-step at the source statement level.
Source mode is the default. In instruction mode, the source window contains disassembled machine instructions, interspersed with source code, if available. Although the source window contains machine instructions, control it with all regular debugger commands. In this mode, the s, i, and o debugger commands are interpreted as their machine instruction counterparts, the si, ii, and oi commands. The b command is interpreted as bi, setting a breakpoint at the machine instruction under the cursor. All searching and window control commands are available.
Screen Prompt
Columns 1 and 2 of the dashed line separating the source window from the command window show the screen-mode prompt, *. The prompt alternates between these two columns and is displayed only when the debugger is awaiting a command. Typing input at any other time is treated as type-ahead and/or input to the program under debug
The * alternates between the two columns to indicate that a change occurs in certain, otherwise non-changing, situations. For example, if stopped at a breakpoint in a loop, typing g returns to the same breakpoint. The only change on the screen is the position of the *.
Alert Frequency
The number of instructions stepped appears on the dashed line. This number appears after a step (s) or advance (a) command is entered. The default setting for the initial display is 1000 but change it with the set step_alert number command. After the first 1000 machine instructions are stepped, the alert frequency number on the dashed line is incremented each time 100 additional instructions are stepped. Change the default value of 100 with the set alert_freq number command.
Help
The screen mode H command displays a line of help text in the error window. This is one of several lines of help text that summarize all screen mode commands. The next help line is displayed each time the H key is pressed.
Window Control Commands
Window control commands control the screen interface. The pattern-matching commands / and ? move the cursor to the bottom of the screen and prompt for the pattern. To terminate the pattern, press either ESC or Return.
You can precede some commands with an optional number. When number is given for a Control-D or Control-U command (scroll up or down), that number is used with all subsequent Control-D and Control-U commands until a new number is specified. The initial value of number is one-half the size of the window.
Table 5 lists the window control commands. Note that window control commands are case sensitive.
Immediate Debugger Commands
Table 6 lists shows the immediate debugger commands. Enter these commands without a preceding : or a following Return in screen mode. In addition, you can enter any line-mode debugger command by typing a colon first. In response to the colon, the screen interface scrolls one line up the command window, positions the cursor on the bottom line of the command window and prompts with a colon. Now enter any line-mode debugger command followed by Return. After each such debugger command, the cursor returns to the source window.
Screen Interface and set output
The set output [pty|tty||filename] option displays input and output from the program being debugged in screen mode without overwriting the source window. With set output pty, the debugger intercepts the program output that is displayed in the command (lower) window. This is the default. Terminal input required by the program is taken from the lower window. With set output tty, the output from a program is displayed on the screen beginning at the cursor location.
When debugging programs that send cursor-positioning strings to the terminal, it is useful to alternate between screen and line mode or type :Return as many times as necessary to clear the bottom portion of the screen of all cursor-positioning strings and then refresh the display with Control-R.
List of All CommandsThis section contains a list of all the commands that can be entered using the non-GUI debugger or the Command Pane of the debugger GUI.
- attach
- b
Set breakpoint at a line or beginning of a subprogram
- bd
Set breakpoint after current subprogram
- bi
Set breakpoint at machine instruction
- br
Set permanent breakpoint at return
- bw
- catch
Catch exception, break when a language exception occurs
- cb
Move to the bottom frame of the call stack
- cd
- cs
- ct
Move to the top frame of the call stack
- cu
- d
- define
- detach
- dm
- edit
Invoke the editor on a or file
- em
- env
- exit
Terminate the debugger session
- g
Continue executing the program
- gs
Continue execution and pass the signal to the program (Native only)
- gw
Continue executing until a variable changes
- help
Invoke debugger manual (Command Pane only)
- i
- Step into program over function calls
- ii
Single step one machine instruction into program
- is
Step into, pass signal to program (Native only)
- kill program
- kill task
- l
Display part of a source program
- lb
List all currently set breakpoints
- le
- li
List disassembled instructions
- lm
- load
Download the memory image to the target (Apex Embedded only)
- lp
- lt
List all active tasks (Ada only)
- lu
List UNIX process(es) (Ada only)
- lv
- o
Step one source line over calls
- oi
Step over one machine instruction over calls
- os
Step over, pass the signal to the program (Native only)
- p
Display the value of a variable or expression
- pass
Pass a command to the target controlling agent (Apex Embedded only)
- pm
- priority task
Change task priority. (Ada only)
- propagate
Propagate exception, break when an exception occurs
- quit
Terminate the debugger session
- r
- raise
- read
Read debugger commands from a file
- reg
List the current machine register contents
- resume program
- resume task
Resume task(s) execution (Ada only)
- Return
- return
Return from all called function
- s
- select program
- select task
- set
- sh
- si
Single step one machine instruction into program
- ss
Single step, pass the signal to the program (Native only)
- state
- stop
- suspend program
- suspend task
- sync
Set/reset debugger knowledge of target (Apex Embedded only)
- v
Navigate to a declaration, subprogram or source file (like vi tags)
- vb
Move source location to breakpoint
- w
List a group of source lines surrounding a line
- wi
Rational Software Corporation http://www.rational.com support@rational.com techpubs@rational.com Copyright © 1993-2002, Rational Software Corporation. All rights reserved. |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |