HP 3000 Manuals HP 3000 Manuals
Entering Commands (cont.)
Entering Procedure Calls (cont.)
Breakpoint Creation Commands
b (breakpoint)
{b } [location] [\count] [command-list]
{breakpoint}
Sets a breakpoint at the location that you specify. If you do not enter
a location, the current line in the source window is used. The
breakpoint is executed on each occurrence (count) that you specify. You
can enter a list of commands to be executed at the breakpoint by entering
the command list. The command list will be executed when the breakpoint
is reached and its count is zero. See the definition for location,
count, and command list at the beginning of this section, "Breakpoint
Commands".
In the following example, a breakpoint is set at the current location in
the source window and is executed every fourth execution of the source
statement. Since there is no command list, no commands are executed when
the breakpoint is reached. Instead, the debugger will just enter command
mode at that point.
> b \4
To set a breakpoint in a different file, procedure, or HP COBOL II
subprogram, use the v (view) command to display the file, procedure, or
subprogram in the current viewing location window and search for the line
on which to set the breakpoint. If you know where to set the breakpoint
in another file, procedure, or subprogram enter this command with the
procedure and line. For example, the following command sets a breakpoint
at line 355 in procedure cmp80.
>b cmp80:355
To set a breakpoint using a label instead of a line number, enter the
label name instead of the line number. For example,
>b cmp80#totsls
ba (breakpoint address)
{ba } address [\count] [command-list]
{breakpoint address}
Sets a breakpoint at the specified address. Note that the address can be
specified by giving the name of a procedure, subprogram, or an expression
containing such a name. The breakpoint is executed on each occurrence
(count) that you specify. You can enter a list of commands to be
executed at the breakpoint by entering the command list. See the
definition for address (location), count, and command list at the
beginning of this section, "Breakpoint Commands".
The following is an example:
>ba printf+0x0018
Overall breakpoints state: ACTIVE
Added:
2: count: 1 Active printf +0x00000018: (line unknown)
CAUTION Be sure the address given in the ba (breakpoint address) command
is a code address in the child process or errors might ensue.
bb (breakpoint beginning)
{bb } [depth] [\count] [command-list]
{breakpoint beginning}
Sets a breakpoint at the first executable statement of the procedure or
subprogram at the specified depth on the program stack. If you do not
enter a depth, the procedure or subprogram shown in the source window is
used (this might not be the same as the procedure or subprogram at depth
zero in the stack).
The breakpoint is executed on the occurrence (count) that you specify.
You can enter a list of commands to be executed at the breakpoint by
entering the command list. See the definitions for count and command
list at the beginning of this section, "Breakpoint Commands".
bt (breakpoint trace)
{bt } [proc ] [\count] [command-list]
{breakpoint trace} [depth]
Sets a trace breakpoint at the current or named procedure or subprogram
or at the procedure or subprogram that is at the specified depth on the
program stack. A breakpoint is set at the entry and exit point of the
procedure or subprogram. The breakpoint is executed on the occurrence
(count) that you specify. You can enter a list of commands to be
executed at the breakpoint by entering the command list. See the
definitions for count and command list at the beginning of this section,
"Breakpoint Commands".
If you include a command list, it is executed at the beginning of the
procedure or subprogram. The following command list will be executed at
the end of the procedure or subprogram.
{Q;p $ret0\d;c}
If you omit a command list, the following two command lists are executed
at the beginning and end of the procedure or subprogram, respectively.
{Q; t 2; c} {Q;p $ret0\d;c}
The first (entry) command list above displays the two procedures at the
top of the stack (the current procedure and the procedure which called
it) and their parameters, then continues. The exit command list prints
the return value of the procedure, then continues.
To enter a different command list for the exit point of the procedure or
subprogram, use the bx (breakpoint exit) command.
bu (breakpoint uplevel)
{bu } [depth] [\count] [command-list]
{breakpoint uplevel}
Sets an uplevel breakpoint to occur immediately on return from the
procedure or subprogram at the specified depth on the program stack.
This command is useful for examining values returned from procedures or
subprograms. For example, when execution pauses in procedure B (called
from procedure A), you can set an uplevel breakpoint so that a breakpoint
occurs when execution returns to procedure A.
If you omit depth, one is used (zero is the current location). The
following example sets a permanent breakpoint at the current level in the
stack (the current level is the value of the program counter $pc):
>bu 0
If $pc corresponds to the beginning of a source line, this is equivalent
to:
>b
The breakpoint is executed on the occurrence (count) that you specify.
You can enter a list of commands to be executed at the breakpoint by
entering the command list. See the definitions for count and command
list at the beginning of this section, "Breakpoint Commands".
bx (breakpoint exit)
{bx } [depth] [\count] [command-list]
{breakpoint exit}
Sets an exit breakpoint at the epilogue code of the procedure or
subprogram at the specified depth on the program stack. The breakpoint
is set at a point such that all returns go through it. If you do not
enter a depth, the procedure shown in the source window is used (this
might not be the same as the procedure at depth zero in the stack).
The breakpoint is executed on the occurrence (count) that you specify.
You can enter a list of commands to be executed at the breakpoint by
entering the command list. See the definitions for count and command
list at the beginning of this section, "Breakpoint Commands".
Breakpoint Status Commands
ab (activate breakpoint)
{ab } [number]
{activate breakpoint} [* ]
Activates the breakpoint having the number (ID) that you specify. If you
do not enter a number, the breakpoint at the current line is activated.
If there is no breakpoint at the current line, the debugger displays all
the breakpoints so that you can select one to activate.
Use the asterisk (*) to activate all breakpoints including, all-procedure
and all-paragraph breakpoints.
bc (breakpoint count)
{bc } number expr
{breakpoint count}
Sets the count of the specified breakpoint number to the integer value of
the evaluated expression that you enter. A negative value indicates a
temporary breakpoint. A count cannot be assigned to an all-procedures or
all-paragraphs breakpoint. Use the lb (list breakpoints) command to
determine the number to enter.
db (delete breakpoint)
{db } [number]
{delete breakpoint} [* ]
Deletes the breakpoint having the number (ID) that you specify. If you
do not enter a number, the breakpoint at the current line is deleted. If
the breakpoint that you specify does not exist, the debugger displays all
the breakpoints so that you can select one to delete.
Use the asterisk (*) to delete all breakpoints, including all-procedure
and all-paragraph breakpoints.
sb (suspend breakpoint)
{sb } [number]
{suspend breakpoint} [* ]
Suspends (deactivates) the breakpoint having the number (ID) that you
specify. If you do not enter a number, the breakpoint at the current
line is suspended (use the lb (list breakpoints) to determine the numbers
to enter). To reactivate the breakpoint use the ab (activate breakpoint)
command.
Use the asterisk (*) to suspend all breakpoints, including all-procedure
and all-paragraph breakpoints. This also causes the overall breakpoint
state to become suspended.
All-Procedures Breakpoint Commands
bp (breakpoint procedure)
{bp } [command-list]
{breakpoint procedure}
Sets permanent procedure breakpoints at the first executable statement of
every procedure for which debugger information is available (this is
equivalent to executing a bb (breakpoint beginning) for every procedure.
The breakpoint is encountered each time the procedure is entered. When
any entry procedure breakpoint is encountered, the command list is
executed. See the definition for command list at the beginning of this
section, "Breakpoint Commands".
This command is useful for stepping through and tracing an HP FORTRAN 77,
HP Pascal, or HP C program. Refer to the bpg (breakpoint paragraph)
command in this chapter for HP COBOL II programs.
The following example sets breakpoints at the beginning of each
procedure. The command list causes the name of the procedure and the
values of its arguments to be displayed before continuing.
bp {Q; t 1; c}
You can set other breakpoints, either permanent or temporary, at the same
locations as the procedure breakpoints without replacing them. However,
if an all-procedure and nonprocedure breakpoint are set at the same
location, the nonprocedure breakpoint is executed first.
You cannot alter the count of a procedure breakpoint. You also cannot
set or delete procedure breakpoints individually. To delete procedure
breakpoints, use the dp command.
bpt
bpt [command-list]
Sets permanent procedure trace breakpoints at the first and last
executable statement of every procedure for which debugger information is
available. The breakpoints are encountered each time the procedure is
entered and exited. The command list, if any, is associated with the
entry breakpoint. See the definition for command list at the beginning
of this section, "Breakpoint Commands".
If no command list is specified, the entry command list defaults to:
{Q;t 2;c}
where:
Q Is the Quiet command that tells the debugger not to display a
breakpoint.
t 2 Pops the top two entries off the stack.
c Is the command used to continue debugging.
The exit command list is:
{Q;p $ret0\d;c}
where:
Q Is the Quiet command that tells the debugger not to display a
breakpoint.
p $ret0\d Displays the value of the special variable ret0 as an integer
value.
c Is the command used to continue debugging.
You can set other breakpoints, either permanent or temporary, at the same
locations as the procedure breakpoints without superceding them.
However, if an all-procedure and nonprocedure breakpoint are set at the
same location, the nonprocedure breakpoint is executed first.
You cannot alter the count of a procedure trace breakpoint. You also
cannot set or delete procedure breakpoints individually. To delete
procedure trace breakpoints, use the dpg command.
bpx
bpx [command-list]
Sets permanent procedure exit breakpoints after the last executable
statement of every procedure for which debugger information is available.
The breakpoint is encountered each time the procedure is exited. When
any procedure exit breakpoint is encountered, the command list is
executed. See the definition for command list at the beginning of this
section, "Breakpoint Commands".
You can set other breakpoints, either permanent or temporary, at the same
locations as the procedure breakpoints without superceding them.
However, if an all-procedure and nonprocedure breakpoint are set at the
same location, the nonprocedure breakpoint is executed first.
You cannot alter the count of a procedure exit breakpoint. You also
cannot set or delete procedure exit breakpoints individually. To delete
procedure exit breakpoints, use the Dpx command.
dp (delete procedure)
{dp }
{delete procedure}
Deletes all procedure breakpoints set with the bp (breakpoint procedure)
command. All breakpoints set by commands other than the bp command will
remain set.
You cannot delete procedure breakpoints individually.
Dpt
Dpt
Deletes all procedure trace breakpoints at the first and last executable
statement of every procedure. All breakpoints set by commands other than
the bpt command will remain in effect.
You cannot delete procedure trace breakpoints individually.
Dpx
Dpx
Deletes all procedure exit breakpoints at the last executable statement
of every procedure. All breakpoints set by commands other than the bpx
command will remain in effect.
You cannot delete procedure exit breakpoints individually.
Global Breakpoint Commands
abc
abc command-list
Defines a global breakpoint command list which will be executed whenever
any user-defined breakpoint is encountered. This includes single,
procedure, procedure trace, procedure exit, paragraph, or paragraph trace
breakpoints. These commands will be executed before any commands
associated with the breakpoint. See the definition for command list at
the beginning of this section, "Breakpoint Commands".
This example suppresses the breakpoint at address message normally
printed for all breakpoints.
>abc Q
dbc
dbc
Deletes the global breakpoint command list.
All-Paragraph Breakpoint Commands
bpg (breakpoint paragraph)
{bpg } [command-list]
{breakpoint paragraph}
Sets permanent paragraph breakpoints at the first executable statement of
every HP COBOL II paragraph and section for which debugger information is
available. The breakpoint is encountered each time the paragraph or
section is entered. When any entry paragraph breakpoint is encountered,
the command list is executed. See the definition for command list at the
beginning of this section, "Breakpoint Commands".
This command is useful for stepping through and tracing an HP COBOL II
program. Refer to the bp (breakpoint procedure) command for HP FORTRAN
77, HP Pascal, and HP C programs.
The following example sets breakpoints at the beginning of each paragraph
and section. The breakpoints are traced quietly without suspending the
program.
>bpg {Q; t 1; c}
You can set other breakpoints, either permanent or temporary, at the same
locations as the paragraph breakpoints without superceding them.
However, if a paragraph and nonparagraph breakpoint are set at the same
location, the nonparagraph breakpoint is executed first.
You cannot alter the count of a paragraph breakpoint. You also cannot
set or delete paragraph breakpoints individually. To delete
all-paragraph breakpoints, use the dpg command.
dpg (delete paragraph)
{dpg }
{delete paragraph}
Deletes all paragraph breakpoints set with the bpg (breakpoint paragraph)
or tpg (trace paragraph) commands. Breakpoints set with other commands
will remain in effect.
You cannot delete individual paragraph breakpoints.
tpg (trace paragraph)
{tpg } [command-list]
{trace paragraph}
Sets permanent paragraph trace breakpoints at the first executable
statement of every HP COBOL II paragraph and section for which debugger
information is available. The breakpoints are encountered each time the
paragraph or section is entered. The command list, if any, is associated
with the entry breakpoint. See the definition for command list at the
beginning of this section, "Breakpoint Commands".
If no command list is specified, the entry command list defaults to:
{Q;t 2;c}
where:
Q Is the Quiet command that tells the debugger not to display a
breakpoint.
t 2 Pops the top two entries off the stack.
c Is the command used to continue debugging.
You can set other breakpoints, either permanent or temporary, at the same
locations as the trace paragraph breakpoints without superceding them.
However, if a paragraph and nonparagraph breakpoint are set at the same
location, the nonparagraph breakpoint is executed first.
You cannot alter the count of a trace paragraph breakpoint. You also
cannot set or delete trace paragraph breakpoints individually. To delete
trace procedure breakpoints, use the Dpt command.
This command is very similar to the bpt command, but differs in the
following ways:
* bpt is targeted at HP FORTRAN 77, HP Pascal, or HP C procedures.
tpg operates on all HP COBOL II paragraphs and sections.
* bpt, by default, prints results upon exiting a procedure. tpg
does not.
Auxiliary Breakpoint Commands
Although the any string, if, and Quiet commands are not actually
breakpoint commands, they are used almost exclusively in breakpoint and
assertion command lists. Consequently, they are documented here.
"any string"
"any string"
Causes any string that is enclosed in quotation marks to be echoed to the
screen. The string command is useful for labeling breakpoint output,
particularly for recording a debugger session. You can include character
escape sequences in the string (for example, \t). See table 4-1 "Escape
Sequences" for more information.
In the following example, the "any string" command is used to label the
display of a data-item which otherwise doesn't have a name (the debugger
just prints an address in such cases). Note the use of the character
escape \n (new line).
>"flavor_list head =>\n"; p *flavor:list->head
flavor_list head =>
0x68023004 struct {
chocolate = 1597845365;
tutifruti = 2.21414e-10;
}
i (if)
{i } expr command-list [command-list]
{if}
Lets you conditionally execute commands in a command list. If the
expression evaluates to a non-zero value, the first group of commands is
executed. If the expression evaluates to zero, the second command list,
if it exists, is executed. The i (if) command can be nested in other
command lists.
The following b (breakpoint) command (set at entry to procedure proc)
uses the i (if) command to conditionally print a value only if a certain
condition is true.
>b proc {Q; if (list->head.fld > 0) {p list->head.name}; c }
Q (Quiet)
{Q }
{Quiet}
Suppresses the breakpoint at address debugger messages that are normally
displayed when a breakpoint is encountered. This enables you to display
variable values without cluttering the command window. The Q (Quiet)
command must be the first command in a command list; otherwise, it is
ignored.
Assertion Control Commands
An assertion is a list of one or more debugger commands that are executed
before each source statement. Assertions are useful for tracing serious
software defects, such as corrupt global variables, or mysterious side
effects. The assertion control commands are:
* a (assert)
* aa (activate assertion)
* da (delete assertion)
* la (list assertions)
* sa (suspend assertion)
* ta (toggle assertions)
* x (exit)
Assertions can be activated or inactivated (suspended) individually.
When an assertion is suspended, information for that assertion is
retained, but it will not be evaluated during program execution. There
is also an overall assertion mode for assertion activation and suspension
which is independent of the state of any individual assertion. Any given
assertion will be evaluated during program execution only if it is
individually activated and the overall mode is activated.
The if, Quiet and "any string" commands are useful in assertion command
lists. For more information about these commands, see the subsection
called "Auxiliary Breakpoint Commands" in the "Breakpoint Commands"
section.
NOTE Assertions slow program execution because the commands for all
active assertions are executed before each source statement. If
you use the assertion commands in a breakpoint command list, you
will be able to limit the regions of slowed execution to your
actual areas of interest in the program.
a (assert)
{a } command-list
{assert}
Creates an assertion consisting of the command list that you enter. You
can enclose an assertion command list in braces to separate it from other
commands on the same line. Errors in assertion command lists are not
identified until the assertion is executed. If there is an error, an
error message is displayed, but execution continues. Assertions, like
breakpoints, are identified by a unique number assigned by the debugger.
They also have an overall state, whereby all assertions can be activated
or suspended as a group. Use the la (list assertions) command to see a
list of assertions, their identifying numbers (ID), and the overall
state.
CAUTION In an assertion command list, you can use the following job
control commands only after an x (exit) command, which suspends
execution of the program.
* r (run)
* R (Run)
* c (continue)
* C (Continue)
* s (step)
* S (Step)
* k (kill)
Also, job control commands cannot be used in an assertion
command list unless all assertions are suspended first. The
following is an example of a typical command list command
sequence.
{l; x 1; c}
The following examples show how to use this command.
a {L}
This "assert list" command traces program execution one line at a time
until the program stops. (The program stops on normal termination, when
a breakpoint is encountered or when CNTRLY is pressed).
a {L; if (xyz> (def-9) *10) {ta;x 1; c} {p abc -= 10}}
This assertion displays the line that will be executed next, then checks
the if statement condition. If it is true, assertion mode and all
assertions are suspended, and the program continues executing. If the
condition is false, the value of abc is decremented by 10, the next
source line is executed, and the command list is executed again. The
number after the exit command (x 1) enables the debugger to recognize the
continue command which follows it. If just x or (x 0) was used, the
remainder of the command would not be executed, and the debugger would
again prompt for commands as if a breakpoint was reached. Note that the
ta (toggle assertions) command is used to toggle assertions to suspend
them because the c (continue) command cannot be used while assertions are
active.
a {if (abc .NE. $abc) {p $abc = abc; if (abc .GT. 9) {x} } p abc}
This command list displays the value of the global variable, abc, and
suspends program execution if the variable exceeds a certain value. $abc
is a special variable that keeps track of when the value of abc changes.
CAUTION If you single step or run with assertions through a call to
longjmp (on setjmp(LIBC)), the child process will probably take
off free-running as the debugger sets but never hits an uplevel
breakpoint.
aa (activate assertion)
{aa } [number]
{activate assertion} [* ]
Activates the assertion having the number (ID) that you enter. Use the
la (list assertions) command to determine the number associated with an
assertion. Using the * option causes all assertions to be activated.
Overall assertion mode is activated if the last suspended assertion is
activated.
da (delete assertion)
{da } [number]
{delete assertion} [* ]
Deletes the assertion having the number (ID) that you enter. Use the la
(list assertions) command to determine the number associated with an
assertion. Using the * option causes all assertions to be deleted.
la (list assertions)
{la }
{list assertions}
Lists the number, the state (active or suspended) and the command list
for each assertion, as well as the overall assertion state (active or
suspended).
Use this command to find the number of a particular assertion before
using the aa (activate assertion), da (delete assertion) and sa (suspend
assertion) commands.
The following example lists the status of two assertions:
Overall assertion state: ACTIVE
1: Active if(abc.NE.$abc){$abc = abc;p abc/d; if(abc.GT.9){x}}
2: Suspended L;if(xyz.GT.(def-9)*10) {ta;x 1;c} {p abc-=10}}
sa (suspend assertion)
{sa } [number]
{suspend assertion} [* ]
Suspends the assertion having the number (ID) that you enter. Use the la
(list assertions) command to determine the number associated with an
assertion. Using the * option causes all assertions to be suspended.
Suspended assertions continue to exist but are not evaluated until
activated again. Overall assertion mode is suspended if the last active
assertion is suspended.
ta (toggle assertions)
{ta }
{toggle assertions}
Toggles the overall assertion state between active and suspended. The
overall assertion state does not affect the state of individual
assertions.
x (exit)
{x } [expr]
{exit}
Causes program execution to stop as if a breakpoint has been reached. A
message like the following will be printed:
Hit on assertion 1: command-list
Last line executed was:
file: source text
Next line to execute is:
file: source text
If the expression (expr) is not given or it evaluates to zero, the
debugger returns to command mode, ignoring any remaining commands in the
assertion command list. If expr evaluates to non-zero, any remaining
commands in the command list are executed.
NOTE This command can only be used in an assertion command list.
Datatrace Control Commands
A datatrace is used to monitor the value of one or more variables. When
the value changes, commands specified in a command list are executed.
Datatraces are useful for tracing serious software defects, such as
corrupt global variables, or mysterious side effects. The datatrace
control commands are:
* ndt
* adt (activate datatrace)
* ddt (delete datatrace)
* ldt (list datatraces)
* sdt (suspend datatrace)
* tdt (toggle datatraces)
* x (exit)
Datatraces can be activated or inactivated (suspended) individually.
When a datatrace is suspended, information for that datatrace is
retained, but it will not be evaluated during program execution. There
is also an overall datatrace mode for datatrace activation and suspension
which is independent of the state of any individual datatrace. Any given
datatrace will be evaluated during program execution only if it is
individually activated and the overall mode is activated.
The if, Quiet and "any string" commands are useful in datatrace command
lists. For more information about these commands, see the subsection
called "Auxiliary Breakpoint Commands" in the "Breakpoint Commands"
section.
NOTE Datatraces slow program execution because the value of the monitor
variables are checked before each source statement. If you use the
datatrace commands in a breakpoint command list, you will be able
to limit the regions of slowed execution to your actual areas of
interest in the program.
ndt (datatrace)
{ndt } var [{command-list}[silent]]
{datatrace}
Creates a datatrace for the specified variable var consisting of the
command list that you enter. You can enclose a datatrace command list in
braces to separate it from other commands on the same line. Errors in
datatrace command lists are not identified until the datatrace is
executed. If there is an error, an error message is displayed, but
execution continues. Datatraces, like breakpoints, are identified by a
unique number assigned by the debugger. They also have an overall state,
whereby all datatraces can be activated or suspended as a group. Use the
ldt (list datatraces) command to see a list of datatraces, their
identifying numbers (ID), and the overall state.
CAUTION In a datatrace command list, you can use the following job
control commands only after an x (exit) command, which suspends
execution of the program.
* r (run)
* R (Run)
* c (continue)
* C (Continue)
* s (step)
* S (Step)
* k (kill)
Also, job control commands cannot be used in a datatrace command
list unless all datatraces are suspended first. The following
is an example of a typical command list command sequence.
{l; x 1; c}
The following examples show how to use this command.
ndt i
This sets a datatrace on variable i. The symbolic debugger will display
the current value of i and stop when that value changes. The default
command list {L} will be used.
ndt i { if(i < 10) {c} }
This sets a datatrace on the variable i, but stops execution only when
the new value reaches or exceeds 10.
ndt i { if(i <= 10) {c} {"i is greater than 10"} } silent
This sets a datatrace on the variable i. When the value of i exceeds 10,
the message:
i is greater than 10
is printed. The silent option prevents the symbolic debugger from
printing the standard messages.
CAUTION If you single step or run with datatraces through a call to
longjmp (on setjmp(LIBC)), the child process will probably take
off free-running as the debugger sets but never hits an uplevel
breakpoint.
adt (activate datatrace)
{adt } [number]
{activate datatrace} [* ]
Activates the datatrace having the number (ID) that you enter. Use the
ldt (list datatraces) command to determine the number associated with a
datatrace. Using the * option causes all datatraces to be activated.
Overall datatrace mode is activated if the last suspended data trace is
activated.
ddt (delete datatrace)
{ddt } [number]
{delete datatrace} [* ]
Deletes the datatrace having the number (ID) that you enter. Use the ldt
(list datatraces) command to determine the number associated with a
datatrace. Using the * option causes all datatraces to be deleted.
ldt (list datatraces)
{ldt }
{list datatraces}
Lists the number, the state (active or suspended) and the command list
for each datatrace, as well as the overall datatrace state (active or
suspended).
Use this command to find the number of a particular datatrace before
using the adt (activate datatrace), ddt (delete datatrace) and sdt
(suspend datatrace) commands.
sdt (suspend datatrace)
{sa } [number]
{suspend datatrace} [* ]
Suspends the datatrace having the number (ID) that you enter. Use the
ldt (list datatraces) command to determine the number associated with a
datatrace. Using the * option causes all datatraces to be suspended.
Suspended datatraces continue to exist but are not evaluated until
activated again. Overall datatrace mode is suspended if the last active
datatrace is suspended.
ta (toggle datatraces)
{tdt }
{toggle datatraces}
Toggles the overall datatrace state between active and suspended. The
overall datatrace state does not affect the state of individual
datatraces.
x (exit)
{x } [expr]
{exit}
Causes program execution to stop as if a breakpoint has been reached. A
message like the following will be printed:
Hit on datatrace 1: command-list
Last line executed was:
file: source text
Next line to execute is:
file: source text
If the expression (expr) is not given or it evaluates to zero, the
debugger returns to command mode, ignoring any remaining commands in the
datatrace command list. If expr evaluates to non-zero, any remaining
commands in the command list are executed.
NOTE This command can only be used in a datatrace command list.
Record and Playback Commands
The record and playback commands allow reproduction of an HP Symbolic
Debugger session by saving debugger commands in a file, which can later
be used to execute the commands. The record and playback commands are
useful for finding bugs that require many debugger actions to isolate or
reproduce. The record-all command is useful for saving a log of the
entire session.
The record and playback commands do not:
* Save debugger responses to commands in the record file. An
exception to this is the record-all command that logs all debugger
output as well as user input to the debugger. Note that a
record-all file cannot be used as a playback file.
* Record commands in command lists for breakpoints and assertions as
they are executed.
* Copy command lines that begin with > , < , :, or ! to the current
record file. However, this limitation can be overridden by
beginning those lines with blanks.
* Record output from the user program (child process). This may be
done using output redirection (>) in the r (run) command line.
The only commands recorded are those read from the keyboard or a playback
file. Commands in a breakpoint or assertion command list are not
recorded as they are evaluated.
Table 4-5 lists the record and playback commands and table 4-6 lists the
record-all commands. These are used to log all of the output generated
in the command window by the debugger. Output generated by the child
process is not recorded.
CAUTION Be careful not to try to play back from a file currently opened
for recording or record from a file currently opened for
playback. This could cause problems with your debugger session.
Record and Playback Commands
Table 4-5. Record and Playback Commands
--------------------------------------------------------------------------------------------
| | |
| Command | Description |
| | |
--------------------------------------------------------------------------------------------
| | |
| >file | Sets or changes the record file to file, turns recording on, |
| | rewrites the file from the beginning, and only records commands. |
| | If file exists, you are asked if you want to overwrite. |
| | |
--------------------------------------------------------------------------------------------
| | |
| >>file | Sets or changes the record file to file, turns recording on, and |
| | only records commands. All recording is appended to the |
| | existing file; otherwise, a new file is created. |
| | |
--------------------------------------------------------------------------------------------
| | |
| > | Displays the recording state and the current recording file. |
| | Can also use ">>". |
| | |
--------------------------------------------------------------------------------------------
| | |
| <file | Starts playback from the file. |
| | |
--------------------------------------------------------------------------------------------
| | |
| <<file | Starts playback from the file using the "line-at-a-time" |
| | feature. Each command line from the playback file is shown |
| | before it is executed, and the debugger provides a list of the |
| | following commands for you to take some action: |
| | |
| | command (<cr>,S, <num>, C, Q, or ?): |
| | |
| | You can use any of the above options as described: |
| | |
| | <cr> execute one command line |
| | S skip one command line |
| | <num> execute number of command lines |
| | C continue through all playback |
| | Q quit playback mode |
| | ? gives this explanation of the above |
| | commands |
| | |
--------------------------------------------------------------------------------------------
| | |
| tr | Toggles recording; toggles the state of the record mechanism |
| | between active and suspended. |
| | |
--------------------------------------------------------------------------------------------
| | |
| >t | Turns recording on. (active) |
| | |
--------------------------------------------------------------------------------------------
| | |
| >f | Turns recording off. (suspended) |
| | |
--------------------------------------------------------------------------------------------
| | |
| >c | Closes the record file. |
| | |
--------------------------------------------------------------------------------------------
Table 4-6. Commands Used to Record Debugger Output
--------------------------------------------------------------------------------------------
| | |
| Command | Description |
| | |
--------------------------------------------------------------------------------------------
| | |
| >@file | Sets or changes the record-all file to file, rewrites from the |
| | beginning, and turns recording on. If file exists, you are |
| | asked if you want to overwrite. Captures all input to and |
| | output from the debugger command window, except user program |
| | output. |
| | |
--------------------------------------------------------------------------------------------
| | |
| >>@file | Sets or changes the record-all file to file, and turns recording |
| | on. Appends record-all output to the existing file. Captures |
| | all input to and output from the debugger command window. |
| | |
--------------------------------------------------------------------------------------------
| | |
| >@ | Displays the current record-all state and file. Can also use |
| | ">>@". |
| | |
--------------------------------------------------------------------------------------------
| | |
| tr @ | Toggles the state of the record-all mechanism between active and |
| | suspended. |
| | |
--------------------------------------------------------------------------------------------
| | |
| >@t | Turns record-all on. |
| | |
--------------------------------------------------------------------------------------------
| | |
| >@f | Turns record-all off. |
| | |
--------------------------------------------------------------------------------------------
| | |
| >@c | Closes the record-all file. |
| | |
--------------------------------------------------------------------------------------------
Macro Facility Commands
The macro facility allows you to substitute your own names for debugger
commands or sequences of debugger commands. To do so, you simply define
the text to be used as a straight replacement for the macro name.
Thereafter, you can use your newly defined macro name to represent the
debugger commands while inside a debugger session.
NOTE Macros do not allow argument substitution and are only recognized
when used where a command is valid. They cannot be used to modify
debugger command syntax.
When defining a macro, replacement text is not immediately scanned for
additional macro invocations. Rather, macro substitutions are performed
as late as possible by HP Symbolic Debugger. This means that when a
macro is referenced and has been evaluated, its replacement text is
rescanned to determine if the replacement text contains any additional
macros. Macros are not recognized inside character constants, strings,
or comment (#) commands during command line processing.
Debugger commands can be redefined by a macro. However, redefining a
debugger command does not redefine its abbreviation. Each must be
redefined separately to change the meaning of both. For example,
redefining the list breakpoints command as bplist has no effect on the lb
abbreviation.
The invocation of recursive macros is trapped and terminates with an
error message. Recursive macros are macros whose replacement text
contains another reference to the same macro, or to a macro whose
expansion eventually references the same macro. For example,
define a a
is flagged as an error.
Macros are not recognized unless the state of the macro mechanism is
activated with the tm (toggle macros) command. If you want to see a list
of your macros and their current state (active or suspended), use the lm
(list macros) command.
def
def name replacement-text
Defines a macro substitution (user-defined command) for HP Symbolic
Debugger commands. Name can be any string of letters or digits,
beginning with a letter. Replacement-text can be any string of letters,
blanks, tabs or other printing characters that represent one or more
debugger commands. The string begins with the first non-white-space
character following name and ends with the first RETURN. For example,
executing this command:
>def myprint p flavor:list->head.tuttifrutti
myprint ==> p flavor:list->head.tuttifrutti
creates a macro called myprint which can be entered at the debugger
prompt in the place of typing:
p flavor:list->head.tuttifrutti
NOTE If a macro can be defined with the same name as a previous macro,
The new definition will replace the old one, until it is undefined
with the undef command, at which point the old definition is
active.
tm (toggle macros)
{tm }
{toggle macros}
Toggles the state of the macro mechanism between active and suspended.
When macros are suspended, the currently defined macros continue to
exist, but are not replaced in the command line by their definitions.
Additional macros can be defined while the macro state is suspended.
undef
undef {name}
{* }
Removes the macro defined by name. Using the * option causes all macros
to become undefined.