there are 'holes' in the address space of the object, then
multiple address ranges will be used to describe the valid
address space.
8.7 LIST_BREAKPOINTS Command
The host sends a LIST_BREAKPOINTS command to request a list
of all breakpoints associated with the current connection. The
target replies with BREAKPOINT_LIST.
Page 79
RFC-909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT |LIST_BREAKPOINTS
+---------------+---------------+
LIST_BREAKPOINTS Command Format
Figure 51
8.8 BREAKPOINT_LIST Reply
The target sends a BREAKPOINT_LIST reply to the host in
response to a LIST_BREAKPOINTS command. The reply contains the
sequence number of the LIST_BREAKPOINTS request, and a list of
all breakpoints associated with the current connection. The
descriptor and address of each breakpoint are listed.
Page 80
LDP Specification Management Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | MANAGEMENT |BREAKPOINT_LIST|
+---------------+---------------+
2 | List Sequence Number |
+---------------+---------------+
3 | Flags |M| Item Count |
+---------------+---------------+ +-+
4 | Mode | 0 | |
+---------------+---------------+ |
5 | | | Breakpoint
+-- ID --+ | Descriptor
6 | Field | |
+---------------+---------------+ +-+
7 | Mode | Mode Argument | |
+---------------+---------------+ |
8 | | |
+-- ID --+ | Breakpoint
9 | Field | | Address
+-------------------------------+ |
10| | |
+-- Offset --+ |
11| | |
+-------------------------------+ +-+
* | Additional
* | Descriptor-Address
* | Pairs
+-+
BREAKPOINT_LIST Reply Format
Figure 52
BREAKPOINT_LIST FIELDS:
List Sequence Number
The sequence number of the LIST_BREAKPOINTS command to which
this is the reply.
Flags
Page 81
RFC-909 July 1984
If M=1, the breakpoint list is continued in one or more
subsequent BREAKPOINT_LIST replies. If M=0, this is the
final BREAKPOINT_LIST.
Item Count
The number of breakpoints described in this list.
Breakpoint Descriptor
A descriptor assigned by the target to this breakpoint.
Used by the host to specify this breakpoint in
BREAKPOINT_DATA and DELETE commands.
Breakpoint Address
The address at which this breakpoint is set.
8.9 LIST_PROCESSES Command
The host sends a LIST_PROCESSES command to request a list of
descriptors for all processes on the target. The target replies
with PROCESS_LIST.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT |LIST_PROCESSES |
+---------------+---------------+
LIST_PROCESSES Command Format
Figure 53
Page 82
LDP Specification Management Commands
8.10 PROCESS_LIST Reply
The target sends a PROCESS_LIST reply to the host in
response to a LIST_PROCESSES command. The reply contains the
sequence number of the LIST_PROCESSES request, and a list of all
processes in the target. For each process, a descriptor and a
target-dependent amount of process data are given.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | MANAGEMENT | PROCESS_LIST |
+---------------+---------------+
2 | List Sequence Number |
+---------------+---------------+
3 | Flags |M| Item Count |
+---------------+---------------+ +-+
4 | PROCESS_CODE | 0 | |
+---------------+---------------+ |
5 | | | Process
+-- ID --+ | Descriptor
6 | Field | |
+---------------+---------------+ +-+
7 | Process data count | |
+---------------+---------------+ |
8 | Process data | Process data | |
+-------------------------------+ | Process
* | Data
* |
* |
+---------------+---------------+ |
n | Process data | Process data | |
+-------------------------------+ +-+
* | Additional
* | Descriptor-Data
* | Pairs
+-+
PROCESS_LIST Reply Format
Figure 54
Page 83
RFC-909 July 1984
PROCESS_LIST FIELDS:
List Sequence Number
The sequence number of the LIST_PROCESSES command to which
this is the reply.
Flags
If M=1, the process list is continued in one or more
subsequent PROCESS_LIST replies. If M=0, this is the final
PROCESS_LIST.
Item Count
The number of processes described in this list. For each
process there is a descriptor and a variable number of
octets of process data.
Process Descriptor
A descriptor assigned by the target to this process. Used
by the host to specify this PROCESS in a DELETE command.
Process Data Count
Number of octets of process data for this process. Must be
even.
Process Data
Target-dependent information about this process. Number of
octets is given by the process data count.
8.11 LIST_NAMES Command
The host sends a LIST_NAMES command to request a list of
available names as strings. The target replies with NAME_LIST.
Page 84
LDP Specification Management Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT | LIST_NAMES |
+---------------+---------------+
LIST_NAMES Command Format
Figure 55
8.12 NAME_LIST Reply
The target sends a NAME_LIST reply to the host in response
to a LIST_NAMES command. The reply contains the sequence number
of the LIST_NAMES request, and a list of all target names, as
strings.
Page 85
RFC-909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | MANAGEMENT | NAME_LIST |
+---------------+---------------+
2 | List Sequence Number |
+---------------+---------------+
3 | Flags |M| Item Count |
+---------------+---------------+ +-+
4 | Name Size | |
+---------------+---------------+ |
5 | Name Char | Name Char | | Name
+---------------+---------------+ | String
* |
* |
* |
+---------------+---------------+ |
n | 0 or Name Char| 0 | |
+---------------+---------------+ +-+
* | Additional
* | Name
* | Strings
+-+
NAME_LIST Reply Format
Figure 56
NAME_LIST FIELDS:
List Sequence Number
The sequence number of the LIST_NAMES command to which this
is the reply.
Page 86
LDP Specification Management Commands
Flags
If M=1, the name list is continued in one or more subsequent
NAME_LIST replies. If M=0, this is the final NAME_LIST.
Item Count
The number of name strings in this list. Each name string
consists of a character count and a null-terminated string
of characters.
Name Size
The number of octets in this name string. Must be even.
Name Characters
A string of octets composing the name. Ends with a null
octet. The number of characters must be even, so if the
terminating null comes on an odd octet, another null is
appended.
8.13 GET_PHYS_ADDR Command
The host sends a GET_PHYS_ADDR command to convert an address
into physical form. The target returns the physical address in a
GOT_PHYS_ADDR reply. For example, the host could send a
GET_PHYS_ADDR command containing a register-offset address, and
the target would return the physical address derived from this in
a GOT_PHYS_ADDR reply.
Page 87
RFC-909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | MANAGEMENT | GET_PHYS_ADDR |
+---------------+---------------+ +-+
2 | Mode | Mode Argument | |
+---------------+---------------+ |
3 | ID | |
+-- Field --+ |
4 | | | Address
+---------------+---------------+ |
5 | | |
+-- Offset --+ |
6 | | |
+---------------+---------------+ +-+
GET_PHYS_ADDR Command Format
Figure 57
GET_PHYS_ADDR FIELDS:
Address
The address to be converted to a physical address. The mode
may be one of PHYS_REG_OFFSET, PHYS_REG_INDIRECT,
PHYS_MACRO_PTR, any OBJECT_* mode, and any PROCESS_* mode
except for PROCESS_REG.
8.14 GOT_PHYS_ADDR Reply
The target sends a GOT_PHYS_ADDR reply to the host in
response to a successful GET_PHYS_ADDR command. The reply
contains the sequence number of the GET_PHYS_ADDR request, and
the specified address converted into a physical address.
Page 88
LDP Specification Management Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 16 |
+---------------+---------------+
1 | MANAGEMENT | GOT_PHYS_ADDR |
+---------------+---------------+
2 | Get Sequence Number |
+---------------+---------------+ +-+
3 | PHYS_MACRO | 0 | |
+---------------+---------------+ |
4 | | |
+-- 0 --+ |
5 | | | Address
+---------------+---------------+ |
6 | | |
+-- Offset --+ |
7 | | |
+---------------+---------------+ +-+
GOT_PHYS_ADDR Reply Format
Figure 58
GOT_PHYS_ADDR FIELDS:
Get Sequence Number
The sequence number of the GET_PHYS_ADDR command to which
this is the reply.
Address
The address resulting from translating the address given in
the GET_PHYS_ADDR command into a physical address. Mode is
always PHYS_MACRO and ID and mode argument are always zero.
Offset gives the 32-bit physical address.
Page 89
RFC-909 July 1984
8.15 GET_OBJECT Command
The host sends a GET_OBJECT command to convert a name string
into a descriptor. The target returns the descriptor in a
GOT_OBJECT reply. Intended for use in finding control parameter
objects.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | MANAGEMENT | GET_OBJECT |
+---------------+---------------+ +-+
2 | Name Size | |
+---------------+---------------+ |
3 | Name Char | Name Char | | Name
+---------------+---------------+ | String
* |
* |
* |
+---------------+---------------+ |
n | 0 or Name Char| 0 | |
+---------------+---------------+ +-+
GET_OBJECT Command Format
Figure 59
GET_OBJECT FIELDS:
Name String
The name of an object.
Name Size
The number of octets in this name string. Must be even.
Name Characters
A string of octets composing the name. Ends with a null
octet. The number of characters must be even, so if the
Page 90
LDP Specification Management Commands
terminating null comes on an odd octet, another null is
appended.
8.16 GOT_OBJECT Reply
The target sends a GOT_OBJECT reply to the host in response
to a successful GET_OBJECT command. The reply contains the
sequence number of the GET_OBJECT request, and the specified
object name converted into a descriptor.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 12 |
+---------------+---------------+
1 | MANAGEMENT | GOT_OBJECT |
+---------------+---------------+
2 | Get Sequence Number |
+---------------+---------------+ +-+
3 | Mode | Mode Argument | |
+---------------+---------------+ |
4 | | |
+-- ID --+ | Object
5 | | | Descriptor
+---------------+---------------+ +-+
GOT_OBJECT Reply Format
Figure 60
GOT_OBJECT FIELDS:
Get Sequence Number
The sequence number of the GET_OBJECT command to which this
is the reply.
Descriptor
Page 91
RFC-909 July 1984
The descriptor of the object named in the GET_OBJECT
command.
Page 92
LDP Specification Breakpoints and Watchpoints
CHAPTER 9
Breakpoints and Watchpoints
Breakpoints and watchpoints are used in debugging
applications. Each breakpoint or watchpoint is associated with
one debugger connection and one address. When a breakpoint or
watchpoint is triggered, the target executes one or more commands
associated with it. A breakpoint is triggered when its address
is executed. A watchpoint is triggered when its address is
modified. The same mechanism is used for structuring breakpoint
and watchpoint commands. For brevity's sake, 'breakpoint' will
be used in the remainder of this document to refer to either a
breakpoint or a watchpoint.
The commands used by the host to manipulate breakpoints are
given in Figure 61, in the order in which they are normally used.
All commands are sent from the host to the target, and each
specifies the descriptor of a breakpoint.
Command Description
---------------------+------------------------------------
CREATE Create a breakpoint
BREAKPOINT_DATA Send commands to be executed in an
FSM breakpoint
START Activate a breakpoint, set state
and initialize breakpoint variables
STOP Deactivate a breakpoint
CONTINUE Activate a breakpoint
LIST_BREAKPOINTS List all breakpoints
REPORT Report the status of a breakpoint
DELETE Delete a breakpoint
Commands to Manipulate Breakpoints
Figure 61
Page 93
RFC-909 July 1984
There are two kinds of breakpoints: default breakpoints and
finite state machine (FSM) breakpoints. They differ in their use
of commands.
Default breakpoints do not contain any commands. When
triggered, a default breakpoint stops the target object (i.e.,
target process or application) it is located in. A STATUS report
on the stopped object is sent to the host. At this point, the
host may send further commands to debug the target.
An FSM breakpoint has one or more conditional command lists,
organized into a finite state machine. When an FSM breakpoint is
created, the total number of states is specified. The host then
sends commands (using BREAKPOINT_DATA) to be associated with each
state. The target maintains a state variable for the breakpoint,
which determines which command list will be executed if the
breakpoint is triggered. When the breakpoint is created its
state variable is initialized to zero (zero is the first state).
A breakpoint command, SET_STATE, may be used within a breakpoint
to change the value of the state variable. A REPORT command
applied to a breakpoint descriptor returns its address, whether
it is armed or disarmed, and the value of its state variable.
Commands valid in breakpoints include all implemented data
transfer and control commands, a set of conditional commands, and
a set of breakpoint commands. The conditional commands and the
breakpoint commands act on a set of local breakpoint variables.
The breakpoint variables consist of the state variable, a
counter, and two pointer variables. The conditional commands
control the execution of breakpoint command lists based on the
contents of one of the breakpoint variables. The breakpoint
commands are used to set the value of the breakpoint variables:
SET_STATE sets the state variable, SET_PTR sets one of the
pointer variables, and INC_COUNT increments the breakpoint
counter. There may be implementation restrictions on the number
of breakpoints, the number of states, the number of conditions,
and the size of the command lists. Management commands and
protocol commands are forbidden in breakpoints.
In FSM breakpoints, the execution of commands is controlled
as follows. When a breakpoint is triggered, the breakpoint's
state variable selects a particular state. One or more
conditional command lists is associated with this state. A
conditional command list consists of a list of conditions
followed by a list of commands which are executed if the
condition list is satisfied. The debugger starts a breakpoint by
executing the first of these lists. If the condition list is
Page 94
LDP Specification Breakpoints and Watchpoints
satisfied, the debugger executes the associated command list and
leaves the breakpoint. If the condition list fails, the debugger
skips to the next conditional command list. This process
continues until the debugger either encounters a successful
condition list, or exhausts all the conditional command lists for
the state. The relationship of commands, lists and states is
shown in Figure 62 (IFs, THENs and ELSEs are used below to
clarify the logical structure within a state; they are not part
of the protocol).
State 0
IF <condition list 0>
THEN <command list 0>
ELSE IF <condition list 1>
THEN <command list 1>
*
*
*
ELSE IF <condition list n>
THEN <command list n>
ELSE <exit>
*
*
*
State n
Breakpoint Conditional Command Lists
Figure 62
9.1 BREAKPOINT_DATA Command
BREAKPOINT_DATA is a data transfer command used by the host
to send commands to be executed in breakpoints and watchpoints.
The command specifies the descriptor of the breakpoint or
watchpoint, and a stream of commands to be appended to the end of
the breakpoint's command list. BREAKPOINT_DATA is applied
sequentially to successive breakpoint states, and successive
Page 95
RFC-909 July 1984
command lists within each state. Multiple BREAKPOINT_DATAs may
be sent for a given breakpoint. Breaks between BREAKPOINT_DATA
commands may occur anywhere within the data stream, even within
individual commands in the data. Sufficient space to store the
data must have been allocated by the maximum size field in the
CREATE BREAKPOINT/WATCHPOINT command.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | DATA_TRANSFER |BREAKPOINT_DATA|
+---------------+---------------+ +-+
2 | Mode | Mode Argument | |
+---------------+---------------+ | Breakpoint or
3 | | | Watchpoint
+-- ID --+ | Descriptor
4 | Field | |
+-------------------------------+ +-+
5 | Data | Data | |
+-------------------------------+ |
* |
* | Data
* |
+---------------+---------------+ |
n | Data | Data or 0 | |
+---------------+---------------+ +-+
BREAKPOINT_DATA Command Format
Figure 63
BREAKPOINT_DATA FIELDS:
Command Length
Total length of this command in octets, including data,
excluding the final padding octet, if any.
Data
A stream of data to be appended to the data for this
breakpoint or watchpoint. This stream has the form of one
or more states, each containing one or more conditional
Page 96
LDP Specification Breakpoints and Watchpoints
command lists. The first BREAKPOINT_DATA command sent for a
breakpoint contains data starting with state zero. The data
for each state starts with the state size. A conditional
command list is composed of two parts: a condition list, and
a command list. Each list begins with a word that gives its
size in octets.
<state 0 size>
<condition list 0 size> <condition list 0>
<command list 0 size> <command list 0>
*
*
*
<condition list n size> <condition list n>
<command list n size> <command list n>
<state 1 size>
<etc>
*
*
*
<state n size>
Breakpoint Data Stream Format
Figure 64
Page 97
RFC-909 July 1984
Sizes
All sizes are stored in 16-bit words, and include their own
length. The state size gives the total number of octets of
breakpoint data for the state. The condition list size
gives the total octets of breakpoint data for the following
condition list. A condition list size of 2 indicates an
empty condition list: in this case the following command
list is executed unconditionally. The command list size
gives the total octets of breakpoint data for the following
command list.
Lists
Condition and command lists come in pairs. When the
breakpoint occurs, the condition list controls whether the
following command list should be executed. A condition list
consists of one or more commands from the CONDITION command
class. A command list consists one or more LDP commands.
Valid commands are any commands from the BREAKPOINT,
DATA_TRANSFER or CONTROL command classes.
Page 98
LDP Specification Conditional Commands
CHAPTER 10
Conditional Commands
Conditional commands are used in breakpoints to control the
execution of breakpoint commands. One or more conditions in
sequence form a condition list. If a condition list is satisfied
(evaluates to TRUE), the breakpoint command list immediately
following it is executed. (See Breakpoints and Watchpoints,
above, for a discussion of the logic flow in conditional/command
lists.) Conditional commands perform tests on local breakpoint
variables, and other locations. Each condition evaluates to
either TRUE or FALSE. Figure 65 contains a summary of
conditional commands:
Command Description
-----------------------------+------------------------------------
CHANGED <loc> Determine if a location has changed
COMPARE <loc1> <mask> <loc2> Compare two locations, using a mask
COUNT_[EQ | GT | LT] <value> Compare the counter to a value
TEST <loc> <mask> <value> Compare a location to a value
Conditional Command Summary
Figure 65
The rules for forming and evaluating condition lists are:
o consecutive conditions have an implicit logical AND between
them. A sequence of such conditions is called an 'and_list'.
and_lists are delimited by an OR command and by the end of
the condition list.
o the breakpoint OR command may be inserted between any pair of
conditions
o AND takes precedence over OR
o nested condition lists are not supported. A condition list
is simply one or more and_lists, separated by ORs.
Page 99
RFC-909 July 1984
o the condition list is evaluated in sequence until either a
TRUE and_list is found (condition list <- TRUE), or the end
of the condition list is reached (condition list <- FALSE).
An and_list is TRUE if all its conditions are TRUE.
The distillation of these rules into BNF is:
<condition_list> :== <and_list> [OR <and_list>]*
<and_list> :== <condition> [AND <condition>]*
<condition> :== CHANGED | COMPARE | COUNT | TEST
where: OR is a breakpoint command
AND is implicit for any pair of consecutive conditions
For example, the following condition list, with one command per
line,
COUNT_EQ 1
OR
COUNT_GT 10
COUNT_LT 20
evaluates to:
(COUNT = 1) OR (COUNT > 10 AND COUNT < 20)
and will cause the command list that follows it to be executed if
the counter is equal to one, or is between 10 and 20.
10.1 Condition Command Format
Condition commands start with the standard four-octet
command header. The high-order bit of the command type byte is
used as a negate flag: if this bit is set, the boolean value of
the condition is negated. This flag applies to one condition
only, and not to other conditions in the condition list.
Page 100
LDP Specification Conditional Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | CONDITION |N| Type |
+---------------+---------------+
Condition Command Header
Figure 66
10.2 COUNT Conditions
The COUNT conditions (COUNT_EQ, COUNT_GT and COUNT_LT) are
used to compare the breakpoint counter to a specified value. The
counter is set to zero when the breakpoint is STARTed, and is
incremented by the INC_COUNT breakpoint command. The format is
the same for the COUNT_EQ, COUNT_GT and COUNT_LT conditions.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 8 |
+---------------+---------------+
1 | CONDITION |N| Type |
+---------------+---------------+
2 | |
+-- Value --+
3 | |
+---------------+---------------+
COUNT Condition Format
Figure 67
COUNT_* Condition FIELDS:
Page 101
RFC-909 July 1984
Type
One of COUNT_EQ, COUNT_LT and COUNT_GT. The condition is
TRUE if the breakpoint counter is [EQ | LT | GT] the
specified value.
Value
A 32-bit value to be compared to the counter.
10.3 CHANGED Condition
The CHANGED condition is TRUE if the contents of the
specified location have changed since the last time this
breakpoint occurred. Only one location may be specified as the
object of CHANGED conditions per breakpoint. The CHANGED
condition is always FALSE the first time the breakpoint occurs.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | CONDITION |N| CHANGED |
+---------------+---------------+
2 | |
+-- --+
3 | Address |
+-- --+
4 | |
+-- --+
5 | |
+-- --+
6 | |
+---------------+---------------+
CHANGED Condition
Figure 68
Page 102
LDP Specification Conditional Commands
CHANGED FIELDS:
Address
The full 5-word address of the location to be tested by the
CHANGED command.
10.4 COMPARE Condition
The COMPARE condition compares two locations using a mask.
The condition is TRUE if (<loc1> & <mask>) = (<loc2> & <mask>).
Page 103
RFC-909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 28 |
+---------------+---------------+
1 | CONDITION |N| COMPARE |
+---------------+---------------+
2 | |
+-- --+
3 | Address 1 |
+-- --+
4 | |
+-- --+
5 | |
+-- --+
6 | |
+---------------+---------------+
7 | |
+-- Mask --+
8 | |
+-------------------------------+
9 | |
+-- --+
10| Address 2 |
+-- --+
11| |
+-- --+
12| |
+-- --+
13| |
+-------------------------------+
COMPARE Condition
Figure 69
Page 104
LDP Specification Conditional Commands
COMPARE FIELDS:
Address 1
Address 2
The 5-word addresses of the locations to be compared.
Mask
A 32-bit mask specifying which bits in the locations should
be compared.
10.5 TEST Condition
The TEST condition is used to compare a location to a value,
using a mask. The condition is TRUE if (<loc> & <mask>) =
<value>.
Page 105
RFC-909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 22 |
+---------------+---------------+
1 | CONDITION |N| TEST |
+---------------+---------------+
2 | |
+-- --+
3 | Address |
+-- --+
4 | |
+-- --+
5 | |
+-- --+
6 | |
+---------------+---------------+
7 | |
+-- Mask --+
8 | |
+-------------------------------+
9 | |
+-- Value --+
10| |
+-------------------------------+
TEST Condition
Figure 70
TEST FIELDS:
Address
The 5-word address of the location to be compared to the
value.
Mask
A 32-bit mask specifying which bits in the location should
be compared.
Value
A 32-bit value to compare to the masked location.
Page 106
LDP Specification Conditional Commands
Page 107
RFC-909 July 1984
Page 108
LDP Specification Breakpoint Commands
CHAPTER 11
Breakpoint Commands
Breakpoint commands are used to set the value of breakpoint
variables. These commands are only valid within breakpoints and
watchpoints. They are sent from the host to the target as data
in BREAKPOINT_DATA commands. Figure 71 contains a summary of
breakpoint commands:
Command Description
------------------------+-------------------------------------
INCREMENT <location> Increment the specified location
INC_COUNT Increment the breakpoint counter
OR OR two breakpoint condition lists
SET_PTR <n> <location> Set pointer <n> to the contents of
<location>
SET_STATE <n> Set the breakpoint state variable
to <n>
Breakpoint Command Summary
Figure 71
11.1 INCREMENT Command
The INCREMENT command increments the contents of a specified
location. The location may be in any address space writable from
LDP.
Page 109
RFC-909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | BREAKPOINT | INCREMENT |
+---------------+---------------+
2 | |
+-- --+
3 | Address |
+-- --+
4 | |
+-- --+
5 | |
+-- --+
6 | |
+---------------+---------------+
INCREMENT Command Format
Figure 72
INCREMENT FIELDS:
Address
The full address of the location whose contents are to be
incremented.
11.2 INC_COUNT Command
The INC_COUNT command increments the breakpoint counter.
There is one counter variable for each breakpoint. It is
initialized to zero when the breakpoint is created, when it is
armed with the START command, and whenever the breakpoint state
changes. The counter is tested by the COUNT_* conditions.
Page 110
LDP Specification Breakpoint Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | BREAKPOINT | INC_COUNT |
+---------------+---------------+
INC_COUNT Command Format
Figure 73
11.3 OR Command
The OR command delineates two and_lists in a breakpoint
condition list. A condition list is TRUE if any of the OR
separated and_lists in it are TRUE. A breakpoint condition list
may contain zero, one or, many OR commands. See 'Condition
Commands' for an explanation of condition lists.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | BREAKPOINT | OR |
+---------------+---------------+
OR Command Format
Figure 74
Page 111
RFC-909 July 1984
11.4 SET_PTR Command
The SET_PTR command loads the specified breakpoint pointer
with the contents of a location. The pointer variables and the
SET_PTR command are intended to provide a primitive but unlimited
indirect addressing capability. Two addressing modes,
BPT_PTR_OFFSET and BPT_PTR_INDIRECT, are used for referencing the
breakpoint pointers. For example, to follow a linked list, use
SET_PTR to load a pointer with the start of the list, then use
successive SET_PTR commands with addressing mode BPT_PTR_OFFSET
to get successive elements.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 16 |
+---------------+---------------+
1 | BREAKPOINT | SET_PTR |
+---------------+---------------+
2 | Pointer |
+---------------+---------------+
3 | |
+-- --+
4 | Address |
+-- --+
5 | |
+-- --+
6 | |
+-- --+
7 | |
+---------------+---------------+
SET_PTR Command Format
Figure 75
SET_PTR FIELDS:
Pointer
The pointer to be changed. Allowable values are 0 and 1.
Address
Page 112
LDP Specification Breakpoint Commands
The full address of the location whose contents are to be
loaded into the given pointer variable.
11.5 SET_STATE Command
The SET_STATE command sets the breakpoint state variable to
the specified value. This is the only method of changing a
breakpoint's state from within a breakpoint. The breakpoint's
state may be also be changed by a START command from the host.
The state variable is initialized to zero when the breakpoint is
created.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | BREAKPOINT | SET_STATE |
+---------------+---------------+
2 | State Value |
+-------------------------------+
SET_STATE Command Format
Figure 76
SET_STATE FIELDS:
State Value
The new value for the breakpoint state variable. Must not
be greater than the maximum state value specified in the
CREATE BREAKPOINT command that created this breakpoint.
Page 113
RFC-909 July 1984
Page 114
LDP Specification Diagram Conventions
APPENDIX A
Diagram Conventions
Command and message diagrams are used in this document to
illustrate the format of these entities. Words are listed in
order of transmission down the page. The first word is word
zero. Bits within a word run left to right, most significant to
least. However, following a convention observed in other
protocol documents, bits are numbered in order of transmission;
the most significant bit in a word is transmitted first. The bit
labelled '0' is the most significant bit.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 |M| |L|
+---------------+---------------+
1 | Most Sig Octet| Least S. Octet|
+---------------+---------------+
M = most significant bit in word zero,
transmitted first
L = least significant bit in word zero,
transmitted last
Sample Diagram
Figure 77
Page 115
RFC-909 July 1984
Page 116
LDP Specification Command Summary
APPENDIX B
Command Summary
The following table lists all non-breakpoint LDP commands in
alphabetical order, with a brief description of each.
Page 117
RFC-909 July 1984
Sender
Command | Host Target | Function
-------------------+-------------+---------------------------
ABORT X Abort outstanding commands
ABORT_DONE X Acknowledge ABORT
ADDRESS_LIST X Return valid address ranges
BREAKPOINT_DATA X Send breakpoint commands
BREAKPOINT_LIST X Return list of breakpoints
CONTINUE X Resume execution
CREATE X Create target object
CREATE_DONE X Acknowledge CREATE
DELETE X Delete target object
DELETE_DONE X Acknowledge DELETE
EXCEPTION X Report target exception
ERROR X Report error with a host command
ERRACK X Acknowledge ERROR
GET_OBJECT X Get object descriptor from name
GET_PHYS_ADDRESS X Get address in physical form
GOT_OBJECT X Return object descriptor
GOT_PHYS_ADDRESS X Return physical address
HELLO X Initiate LDP session
HELLO_REPLY X Return LDP parameters
LIST_ADDRESSES X Request valid address ranges
LIST_BREAKPOINTS X Request breakpoint list
LIST_NAMES X Request name list
LIST_PROCESSES X Request process list
MOVE X Read data from target
MOVE_DONE X Acknowledge MOVE completion
MOVE_DATA X Send data request by MOVE
NAME_LIST X Return name list
PROCESS_LIST X Return process list
READ X Read data from target
READ_DATA X Return data requested by READ
READ_DONE X Acknowledge READ completion
REPEAT_DATA X Write copies of data
REPORT X Request status of object
START X Start target object
STATUS X Return status of object
STEP X Step execution of target object
STOP X Stop target object
SYNCH X Check sequence number
SYNCH_REPLY X Confirm sequence number
WRITE X Write data
WRITE_MASK X Write data with mask
Page 118
LDP Specification Command Summary
Command Summary
Figure 78
Page 119
RFC-909 July 1984
Page 120
LDP Specification Commands, Responses and Replies
APPENDIX C
Commands, Responses and Replies
The following table shows the relationship between commands,
responses and replies. Commands are sent from the host to the
target. Some commands elicit responses and/or replies from the
target. Responses and replies are sent from the target to the
host. The distinction between them is that the target sends only
one reply to a command, but may send multiple responses.
Responses always contain data, whereas replies may or may not.
Page 121
RFC-909 July 1984
Command | Response | Reply
-------------------+--------------+------------------
ABORT ABORT_DONE
BREAKPOINT_DATA
CONTINUE
CREATE CREATE_DONE
DELETE DELETE_DONE
GET_OBJECT GOT_OBJECT
GET_PHYS_ADDRESS GOT_PHYS_ADDRESS
HELLO HELLO_REPLY
LIST_ADDRESSES ADDRESS_LIST
LIST_BREAKPOINTS BREAKPOINT_LIST
LIST_NAMES NAME_LIST
LIST_PROCESSES PROCESS_LIST
MOVE MOVE_DATA MOVE_DONE
READ READ_DATA READ_DONE
REPEAT_DATA
REPORT STATUS
START
STEP
STOP
SYNCH SYNCH_REPLY
WRITE
WRITE_MASK
Commands, Responses and Replies
Figure 79
Page 122
LDP Specification Glossary
APPENDIX D
Glossary
FSM
Finite state machine. Commands of each breakpoint or
watchpoint are implemented as part of a finite state
machine. A list of breakpoint commands is associated with
each state. There are several breakpoint commands to change
from one state to another.
host
The 'host' in an LDP session is the timesharing system on
which the user process runs.
long
A long is a 32-bit quantity.
octet
An octet is an eight-bit quantity.
RDP
The Reliable Data Protocol (RDP) is a transport layer
protocol designed as a low-overhead alternative to TCP. RDP
is a connection oriented protocol that provides reliable,
sequenced message delivery.
server process
The LDP server process is the passive participant in an LDP
session. The server process usually resides on a target
machine such as a PAD, PSN or gateway. The server process
waits for a user process to initiate a session, and responds
to commands from the user process. In response to user
commands, the server may perform services on the target like
reading and writing memory locations or setting breakpoints.
'Server' is sometimes employed as a shorthand for 'server
process'.
Page 123
RFC-909 July 1984
target
The 'target' in an LDP session is the PSN, PAD or gateway
that is being loaded, dumped or debugged by the host.
Normally, LDP will be implemented in the target as a server
process. However, in some targets with strange
requirements, notably the Butterfly, the target LDP may be a
user process.
user process
The LDP user process is the active participant in an LDP
session. The user process initiates and terminates the
session and sends commands to the server process which
control the session. The user process usually resides on a
timesharing host and is driven by a higher-level entity
(e.g., an application program like an interactive debugger).
'User' is sometimes employed as a shorthand for 'user
process'.
word
A word is a sixteen-bit quantity.
Page 124
INDEX
ABORT command............................................ 35
ABORT_DONE reply......................................... 36
address.............................................. 60, 66
address descriptor....................................... 20
address format................................... 19, 25, 31
address ID............................................... 22
address mode......................................... 20, 22
address mode argument.................................... 21
address offset........................................... 20
addressing............................................... 19
ADDRESS_LIST reply................................... 76, 77
BASIC_DEBUGGER....................................... 12, 32
breakpoint... 9, 13, 57, 60, 71, 79, 92, 93, 95, 96, 99, 107
breakpoint commands.......................... 9, 94, 95, 107
breakpoint counter........................ 94, 100, 101, 110
breakpoint data...................................... 97, 99
breakpoint state variable........................... 94, 107
breakpoint variables..................................... 94
BREAKPOINT_DATA command..................... 73, 94, 95, 107
BREAKPOINT_LIST reply................................ 79, 80
CHANGED condition....................................... 102
command class............................................ 16
command length field..................................... 16
COMPARE Condition....................................... 103
condition command header................................ 101
conditional commands................................. 94, 99
CONTINUE command......................................... 62
control commands...................................... 9, 57
COUNT condition.................................... 110, 111
COUNT_EQ condition...................................... 101
COUNT_GT condition...................................... 101
COUNT_LT condition...................................... 101
CREATE command............................... 69, 70, 73, 75
create types............................................. 70
CREATE_DONE reply.................................... 73, 75
data octets...................................... 43, 47, 52
data packing............................................. 10
data transfer commands................................ 9, 41
data transmission........................................ 10
datagrams................................................. 5
debugging.............................................. 1, 3
Page 125
default breakpoint................................... 71, 92
DELETE command....................................... 73, 75
DELETE_DONE reply........................................ 75
descriptor........... 20, 57, 61, 62, 63, 64, 65, 73, 75, 93
dumping................................................... 3
ERRACK............................................... 10, 39
ERROR codes.............................................. 38
ERROR reply.......................................... 37, 67
EXCEPTION trap........................................... 66
finite state machine................................. 60, 93
FSM breakpoint................................... 71, 92, 94
FULL-DEBUGGER............................................ 12
FULL_DEBUGGER............................................ 32
gateway................................................ 3, 9
GET_OBJECT command................................... 89, 91
GET_PHYS_ADDR command................................ 87, 88
GOT_OBJECT reply..................................... 89, 91
GOT_PHYS_ADDR reply.................................. 87, 88
HELLO command......................................... 9, 29
HELLO_REPLY....................................... 9, 19, 30
host descriptor.......................................... 41
implementation....................................... 12, 31
INC_COUNT command......................... 94, 107, 110, 111
INCREMENT command....................................... 109
internet.................................................. 5
internet protocols........................................ 4
IP........................................................ 5
LDP command formats...................................... 15
LDP header........................................... 15, 16
LDP Version.............................................. 30
LIST commands............................................ 73
LIST_ADDRESSES command............................... 76, 77
LIST_BREAKPOINTS command............................. 79, 80
LIST_NAMES command................................... 84, 85
LIST_PROCESSES command................................... 82
LOADER_DUMPER........................................ 12, 32
loading................................................ 1, 3
long address format...................................... 20
management commands...................................... 67
memory object............................................ 73
MOVE command................................. 22, 41, 47, 49
MOVE sequence number..................................... 52
MOVE_DATA response................................... 22, 51
MOVE_DONE reply.......................................... 52
NAME_LIST reply...................................... 84, 85
offset............................................... 20, 22
OR command.............................................. 111
Page 126
PAD.................................................... 3, 9
pattern.................................................. 54
PHYS_ADDRESS............................................. 57
PHYS_MACRO............................................... 60
PROCESS.................................................. 57
PROCESS_CODE............................................. 60
PROCESS_LIST reply....................................... 82
protocol commands......................................... 9
PSN.................................................... 3, 9
RDP................................................... 5, 15
READ command..................................... 41, 43, 44
READ sequence number..................................... 47
READ_DATA response................................... 45, 46
READ_DONE reply.......................................... 47
repeat count............................................. 54
REPEAT_DATA command.................................. 41, 53
REPORT command................................... 63, 64, 94
sequence number...................................... 10, 39
session................................................... 9
SET_PTR command................................ 94, 111, 112
SET_STATE command.............................. 94, 107, 113
short address format..................................... 25
START command........................................ 59, 60
STATUS reply..................................... 64, 65, 94
STEP command......................................... 62, 63
STOP command......................................... 60, 61
SYNCH.................................................... 10
SYNCH command............................................ 33
SYNCH_REPLY.............................................. 34
system type.............................................. 30
target start address......................... 43, 44, 46, 54
transport................................................. 9
watchpoint.......... 13, 57, 60, 71, 92, 93, 95, 96, 99, 107
WRITE command........................................ 41, 42