As a practical matter, the ABORT command may be difficult to
implement on some targets. Its ability to interrupt command
processing on the target depends on the target being able to look
ahead at incoming commands and receive an out-of-band signal from
the host. However, the effect of an ABORT may be achieved by
simply closing and reopening the transport connection.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | PROTOCOL | ABORT |
+---------------+---------------+
ABORT Command Format
Figure 21
5.6 ABORT_DONE Reply
The ABORT_DONE reply is sent from the target to the host in
response to an ABORT command. This indicates that the target has
terminated all operations that were pending when the ABORT
command was received. The sequence number of the ABORT command
is included in the reply.
Page 35
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 | PROTOCOL | ABORT_DONE |
+---------------+---------------+
2 | Sequence Number |
+---------------+---------------+
ABORT_DONE Reply Format
Figure 22
ABORT_DONE FIELDS:
Sequence Number
The sequence number of the ABORT command that elicited this
reply. This enables the host to distinguish between
replies to multiple aborts.
5.7 ERROR Reply
The ERROR reply is sent by the target in response to a bad
command. The ERROR reply gives the sequence number of the
offending command and a reason code. The target ignores further
commands until an ERRACK command is received. The reason for
ignoring commands is that the proper operation of outstanding
commands may be predicated on the execution of the erroneous
command.
Page 36
LDP Specification Protocol 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 | PROTOCOL | ERROR |
+---------------+---------------+
2 | Command Sequence Number |
+---------------+---------------+
3 | Error code |
+---------------+---------------+
4 | Optional Data |
+---------------+---------------+
*
*
*
+---------------+---------------+
n | Optional Data |
+---------------+---------------+
ERROR Reply Format
Figure 23
ERROR Reply FIELDS:
Command Sequence Number
The implicit sequence number of the erroneous command.
Error Code
A code specifying what error has taken place. The currently
defined codes are shown in Figure 24.
Page 37
RFC-909 July 1984
Error Code | Symbol
-----------+------------------------
1 BAD_COMMAND
2 BAD_ADDRESS_MODE
3 BAD_ADDRESS_ID
4 BAD_ADDRESS_OFFSET
5 BAD_CREATE_TYPE
6 NO_RESOURCES
7 NO_OBJECT
8 OUT_OF_SYNCH
9 IN_BREAKPOINT
ERROR Codes
Figure 24
An explanation of each of these error codes follows:
BAD_COMMAND
The command was not meaningful to the target machine.
This includes commands that are valid but unimplemented
in this target. Also, the command was not valid in
this context. For example, a command given by the host
that is only legal in a breakpoint (e.g. IF,
SET_STATE).
BAD_ADDRESS_MODE <offending-address>
The mode of an address given in the command is not
meaningful to this target system. For example, a
PROCESS address mode on a target that does not support
multi-processing.
BAD_ADDRESS_ID <offending-address>
The ID field of an address didn't correspond to an
appropriate thing. For example, for a PROCESS address
mode, the ID of a non-existent process.
BAD_ADDRESS_OFFSET <offending-address>
The offset field of the address was outside the legal
range for the thing addressed. For example, an offset
of 200,000 in PHYS_MACRO mode on a target with 64K of
Page 38
LDP Specification Protocol Commands
macro-memory.
BAD_CREATE_TYPE
The object type in a CREATE command was unknown.
NO_RESOURCES
A CREATE command failed due to lack of necessary
resources.
NO_OBJECT
A GET_OBJECT command failed to find the named object.
OUT_OF_SYNCH
The sequence number of the SYNCH command was not
expected by the target. The target has resynchronized
to it.
IN_BREAKPOINT <breakpoint-descriptor> <breakpoint-sequence#>
<reason-code> [<optional-info>]
An error occurred within a breakpoint command list.
The given 16-bit sequence-number refers to the sequence
number of the CREATE command that created the
breakpoint, while breakpoint-sequence# refers to the
sequence number of the command within the breakpoint
given by <breakpoint-descriptor>.
5.8 ERRACK Acknowledgement
An ERRACK is sent by the host in response to an ERROR
reply from the target. The ERRACK is used to acknowledge that
the host has received the ERROR reply.
Page 39
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 | PROTOCOL | ERRACK |
+---------------+---------------+
ERRACK Command Format
Figure 25
Page 40
LDP Specification Data Transfer Commands
CHAPTER 6
Data Transfer Commands
Data transfer commands transfer data between the host and
the target. These commands are used for loading and dumping the
target, and examining and depositing locations on the target.
The READ command reads data from the target, the MOVE command
moves data within the target or from the target to another
entity, and the WRITE command writes data to the target.
REPEAT_DATA makes copies of a pattern to the target -- it is
useful for zeroing memory. WRITE_MASK writes data with a mask,
and is intended for modifying target parameter tables.
Data transmitted to and from the target always contains a
target address. In writes to the target, this is used as the
destination of the data. In reads from the target, the target
address is used by the host to identify where in the target the
data came from. In addition, the MOVE command may contain a
'host' address as its destination; this permits the host to
further discriminate between possible sources of data from the
target -- from different breakpoints, debugging windows, etc.
A read request to the target may generate one or more
response messages. In particular, responses to requests for
large amounts of data -- core dumps, for example -- must be
broken up into multiple messages, if the block of data requested
plus the LDP header exceeds the transport layer message size.
In commands which contain data (WRITE, READ_DATA, MOVE_DATA
and REPEAT_DATA), if there are an odd number of data octets, then
a null octet is appended. This is so that the next command in
the message, if any, will begin on an even octet. The command
length is the sum of the number of octets in the command header
and the number of octets of data, excluding the null octet, if
any.
The addressing formats which may be used with data transfer
commands are specified for each LDP session at the start of the
session by the target in the HELLO_REPLY response. See the
section entitled 'Addressing', above, for a description of LDP
addressing formats and modes. In the command diagrams given
below, the short addressing format is illustrated. For LDP
sessions using long addressing, addresses are five words long,
Page 41
RFC-909 July 1984
instead of three words, as shown here. In both addressing modes,
descriptors are three words and offsets are two words.
6.1 WRITE Command
The WRITE command is used to send octets of data from the
host to the target. This command specifies the address in the
target where the data is to be stored, followed by a stream of
data octets. If the data stream contains an odd number of
octets, then a null octet is appended so that the next command,
if any, will begin on an even octet. Since LDP must observe
message size limitations imposed by the underlying transport
layer, a single logical write may need to be broken up into
multiple WRITEs in separate transport messages.
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 | WRITE |
+---------------+---------------+
2 | |
+-- Target --+
3 | Start |
+-- Address --+
4 | |
+---------------+---------------+
5 | Data Octet | Data Octet |
+---------------+---------------+
*
*
*
+---------------+---------------+
n | Data Octet | Data or Null |
+---------------+---------------+
WRITE Command Format
Figure 26
Page 42
LDP Specification Data Transfer Commands
WRITE FIELDS:
Command Length
The command length gives the number of octets in the
command, including data octets, but excluding the padding
octet, if any.
Target Start Address
This is the address to begin storing data in the target.
The length of the data to be stored may be inferred by the
target from the command length. An illegal address or range
will generate an ERROR reply.
Data Octets
Octets of data to be stored in the target. Data are packed
according to the packing convention described above. Ends
with a null octet if there are an odd number of data octets.
6.2 READ Command
The host uses the READ command to ask the target to
send back a contiguous block of data. The data is specified by
a target starting address and a count. The target returns the
data in one or more READ_DATA commands, which give the starting
address (in the target) of each segment of returned data. When
the transfer is completed, the target sends a READ_DONE command
to the host.
Page 43
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 | DATA_TRANSFER | READ |
+---------------+---------------+
2 | |
+-- Target --+
3 | Start |
+-- Address --+
4 | |
+---------------+---------------+
5 | Address |
+-- Unit --+
6 | Count |
+---------------+---------------+
READ Command Format
Figure 27
READ FIELDS:
Target Start Address
The starting address of the requested block of target data.
The target sends an ERROR reply if the starting address is
illegal, if the ending address computed from the sum of the
start and the count is illegal, or if holes are encountered
in the middle of the range.
Address Unit Count
The count of the number of target indivisibly-addressable
units to be transferred. For example, if the address space
is PHYS_MACRO, a count of two and a start address of 1000
selects the contents of locations 1000 and 1001. 'Count' is
used instead of 'length' to avoid the problem of determining
units the length should be denominated in (octets, words,
etc.). The size and type of the unit will vary depending on
the address space selected by the target start address. The
target should reply with an error (if it is able to
Page 44
LDP Specification Data Transfer Commands
determine in advance of a transfer) if the inclusive range
of addresses specified by the start address and the count
contains an illegal or nonexistent address.
6.3 READ_DATA Response
The target uses the READ_DATA response to transmit data
requested by a host READ command. One or more READ_DATA
responses may be needed to fulfill a given READ command,
depending on the size of the data block requested and the
transport layer message size limits. Each READ_DATA response
gives the target starting address of its segment of data. If the
response contains an odd number of data octets, the target ends
the response with a null octet.
Page 45
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 | DATA_TRANSFER | READ_DATA |
+---------------+---------------+
2 | |
+-- Target --+
3 | Start |
+-- Address --+
4 | |
+---------------+---------------+ +-+
5 | Data Octet | Data Octet | |
+---------------+---------------+ |
* |
* | Data
* |
+---------------+---------------+ |
n | Data Octet | Data or Null | |
+---------------+---------------+ +-+
DATA Response Format
Figure 28
READ_DATA FIELDS:
Command Length
The command length gives the number of octets in the
command, including data octets, but excluding the padding
octet, if any. The host can calculate the length of the
data by subtracting the header length from the command
length. Since the target address may be either three words
(short format) or five words (long format), the address mode
must be checked to determine which is being used.
Target Start Address
This is the starting address of the data segment in this
message. The host may infer the length of the data from the
command length. The address format (short or long) is the
Page 46
LDP Specification Data Transfer Commands
same as on the initial READ command.
Data Octets
Octets of data from the target. Data are packed according
to the packing convention described above. Ends with a null
octet if there are an odd number of data octets.
6.4 READ_DONE Reply
The target sends a READ_DONE reply to the host after it has
finished transferring the data requested by a READ command.
READ_DONE specifies the sequence number of the READ command.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | DATA_TRANSFER | READ_DONE |
+---------------+---------------+
2 | READ Sequence Number |
+---------------+---------------+
READ_DONE Reply Format
Figure 29
READ_DONE FIELDS:
READ Sequence Number
The sequence number of the READ command this is a reply to.
Page 47
RFC-909 July 1984
6.5 MOVE Command
The MOVE command is sent by the host to move a block of data
from the target to a specified destination. The destination
address may specify a location in the target, in the host, or in
another target (for loading one target from another). The data
is specified by a target starting address and an address unit
count. The target sends an ERROR reply if the starting address
is illegal, if the ending address computed from the sum of the
start and the count is illegal, or if holes are encountered in
the middle of the range. If the MOVE destination is off-target,
the target moves the data in one or MOVE_DATAs. Other commands
arriving at the target during the transfer should be processed in
a timely fashion, particularly the ABORT command. When the data
has been moved, the target sends a MOVE_DONE to the host.
However, a MOVE within a breakpoint will not generate a
MOVE_DONE.
A MOVE with a host destination differs from a READ in that
it contains a host address. This field is specified by the host
in the MOVE command and copied by the target into the responding
MOVE_DATA(s). The address may be used by the host to
differentiate data returned from multiple MOVE requests. This
information may be useful in breakpoints, in multi-window
debugging and in communication with targets with multiple
processors. For example, the host sends the MOVE command to the
target to be executed during a breakpoint. The ID field in
the host address might be an index into a host breakpoint table.
When the breakpoint executes, the host would use the ID to
associate the returning MOVE_DATA with this breakpoint.
Page 48
LDP Specification Data Transfer 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 | DATA_TRANSFER | MOVE |
+---------------+---------------+
2 | |
+-- Source --+
3 | Start |
+-- Address --+
4 | |
+---------------+---------------+
5 | Address |
+-- Unit --+
6 | Count |
+---------------+---------------+
7 | |
+-- Destination --+
8 | Start |
+-- Address --+
9 | |
+---------------+---------------+
MOVE Command Format
Figure 30
MOVE FIELDS:
Source Start Address
The starting address of the requested block of target data.
An illegal address type will generate an error reply.
Address Unit Count
The count of the number of target indivisibly-addressable
units to be transferred. For example, if the address space
is PHYS_MACRO, a count of two and a start address of 1000
selects the contents of locations 1000 and 1001. 'Count' is
used instead of 'length' to avoid the problem of determining
units the length should be denominated in (octets, words,
Page 49
RFC-909 July 1984
etc.). The size and type of the unit will vary depending on
the address space selected by the target start address. The
target should reply with an error (if it is able to
determine in advance of a transfer) if the inclusive range
of addresses specified by the start address and the count
contains an illegal or nonexistent address.
Destination Address
The destination of the MOVE. If the address space is on the
target, the address unit size should agree with that of the
source address space. If the address mode is HOST, the
values and interpretations of the remaining address fields
are arbitrary, and are determined by the host
implementation. For example, the mode argument might
specify a table (breakpoint, debugging window, etc.) and the
ID field an index into the table.
6.6 MOVE_DATA Response
The target uses the MOVE_DATA responses to transmit data
requested by a host MOVE command. One or more MOVE_DATA
responses may be needed to fulfill a given MOVE command,
depending on the size of the data block requested and the
transport layer message size limits. Each MOVE_DATA response
gives the target starting address of its segment of data. If the
response contains an odd number of data octets, the target should
end the response with a null octet.
Page 50
LDP Specification Data Transfer 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 | DATA_TRANSFER | MOVE_DATA |
+---------------+---------------+
2 | |
+-- Source --+
3 | Start |
+-- Address --+
4 | |
+---------------+---------------+
5 | |
+-- Destination --+
6 | Start |
+-- Address --+
7 | |
+---------------+---------------+ +-+
8 | Data Octet | Data Octet | |
+---------------+---------------+ |
* |
* | Data
* |
+---------------+---------------+ |
n | Data Octet | Data or Null | |
+---------------+---------------+ +-+
MOVE_DATA Response Format
Figure 31
MOVE_DATA FIELDS:
Command Length
The command length gives the number of octets in the
command, including data octets, but excluding the padding
octet, if any.
Source Start Address
This is the starting address of the data segment in this
Page 51
RFC-909 July 1984
message. The host may infer length of the data from the
command length.
Destination Address
The destination address copied from the MOVE command that
initiated this transfer. In the case of HOST MOVEs, this is
used by the host to identify the source of the data.
Data Octets
Octets of data from the target. Data are packed according
to the packing convention described above. Ends with a null
octet if there are an odd number of data octets.
6.7 MOVE_DONE Reply
The target sends a MOVE_DONE reply to the host after it has
finished transferring the data requested by a MOVE command.
MOVE_DONE specifies the sequence number of the MOVE command.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | DATA_TRANSFER | MOVE_DONE |
+---------------+---------------+
2 | MOVE Sequence Number |
+---------------+---------------+
MOVE_DONE Reply Format
Figure 32
MOVE_DONE FIELDS:
MOVE Sequence Number
The sequence number of the MOVE command this is a reply to.
Page 52
LDP Specification Data Transfer Commands
6.8 REPEAT_DATA
The REPEAT_DATA command is sent by the host to write copies
of a specified pattern into the target. This provides an
efficient way of zeroing target memory and initializing target
data structures. The command specifies the target starting
address, the number of copies of the pattern to be made, and a
stream of octets that constitutes the pattern.
This command differs from the other data transfer commands
in that the effect of a REPEAT_DATA with a large pattern cannot
be duplicated by sending the data in smaller chunks over several
commands. Therefore, the maximum size of a pattern that can be
copied with REPEAT_DATA will depend on the message size limits of
the transport layer.
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 | REPEAT_DATA |
+---------------+---------------+
2 | |
+-- Target --+
3 | Start |
+-- Address --+
4 | |
+---------------+---------------+
6 | Repeat Count |
+---------------+---------------+ +-+
7 | Data Octet | Data Octet | |
+---------------+---------------+ |
* |
* | Pattern
* |
+---------------+---------------+ |
n | Data Octet | Data or Null | |
+---------------+---------------+ +-+
REPEAT_DATA Command Format
Figure 33
Page 53
RFC-909 July 1984
REPEAT_DATA FIELDS:
Command Length
The command length gives the number of octets in the
command, including data octets in the pattern, but excluding
the padding octet, if any.
Target Start Address
This is the starting address where the first copy of the
pattern should be written in the target. Successive copies
of the pattern are made contiguously starting at this
address.
Repeat Count
The repeat count specifies the number of copies of the
pattern that should be made in the target. The repeat count
should be greater than zero.
Pattern
The pattern to be copied into the target, packed into a
stream of octets. Data are packed according to the packing
convention described above. Ends with a null octet if there
are an odd number of data octets.
6.9 WRITE_MASK Command (Optional)
The host sends a WRITE_MASK command to the target to write
one or more masked values. The command uses an address to
specify a target base location, followed by one or more offset-
mask-value triplets. Each triplet gives an offset from the base,
a value, and a mask indicating which bits in the location at the
offset are to be changed.
This optional command is intended for use in controlling the
target by changing locations in a table. For example, it may be
used to change entries in a target parameter table. The
operation of modifying a specified location with a masked value
is intended to be atomic. In other words, another target process
should not be able to access the location to be modified between
Page 54
LDP Specification Data Transfer Commands
the start and the end of the modification.
Page 55
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 | DATA_TRANSFER | WRITE_MASK |
+---------------+---------------+
2 | |
+-- Target --+
3 | Base |
+-- Address --+
4 | |
+---------------+---------------+ +-+
5 | | |
+-- Offset --+ |
6 | | |
+---------------+---------------+ | Offset-Mask-Value
7 | | | Triplet
+-- Mask --+ |
8 | | |
+---------------+---------------+ |
9 | | |
+-- Value --+ |
10| | |
+---------------+---------------+ +-+
*
*
*
+---------------+---------------+ +-+
| | |
+-- Offset --+ |
| | |
+---------------+---------------+ | Offset-Mask-Value
| | | Triplet
+-- Mask --+ |
| | |
+---------------+---------------+ |
| | |
+-- Value --+ |
| | |
+---------------+---------------+ +-+
WRITE_MASK Format
Figure 34
Page 56
LDP Specification Data Transfer Commands
WRITE_MASK FIELDS:
Command Length
The command length gives the number of octets in the
command. The number of offset-value pairs may be calculated
from this, since the command header is either 10 or 12
octets long (short or long address format), and each
offset-mask-value triplet is 12 octets long.
Target Base Address
Specifies the target location to which the offset is added
to yield the location to be modified.
Offset
An offset to be added to the base to select a location to be
modified.
Mask
Specifies which bits in the value are to be copied into the
location.
Value
A value to be stored at the specified offset from the base.
The set bits in the mask determine which bits in the value
are applied to the location. The following algorithm will
achieve the intended result: take the one's complement of
the mask and AND it with the location, leaving the result in
the location. Then AND the mask and the value, and OR the
result into the location.
Page 57
RFC-909 July 1984
Page 58
LDP Specification Control Commands
CHAPTER 7
Control Commands
Control commands are used to control the execution of target
code, breakpoints and watchpoints. They are also used to read
and report the state of these objects. The object to be
controlled or reported on is specified with a descriptor. Valid
descriptor modes include PHYS_* (for some commands) PROCESS_CODE,
BREAKPOINT and WATCHPOINT. Control commands which change the
state of the target are START, STOP, CONTINUE and STEP. REPORT
requests a STATUS report on a target object. EXCEPTION is a
spontaneous report on an object, used to report asynchronous
events such as hardware traps. The host may verify the action of
a START, STOP, STEP or CONTINUE command by following it with a
REPORT command.
7.1 START Command
The START command is sent by the host to start execution of
a specified object in the target. For targets which support
multiple processes, a PROCESS_CODE address specifies the process
to be started. Otherwise, one of the PHYS_* modes may specify
a location in macro-memory where execution is to continue.
Applied to a breakpoint or watchpoint, START sets the value of
the object's state variable, and activates the breakpoint. The
breakpoint counter and pointer variables are initialized to zero.
Page 59
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 | CONTROL | START |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | |
+-- ID --+ |
4 | Field | | Address
+-------------------------------+ |
5 | | |
+-- Offset --+ |
6 | | |
+-------------------------------+ +-+
START Command Format
Figure 35
START FIELDS:
Address
The descriptor specifies the object to be started. If the
mode is PROCESS_CODE, ID specifies the process to be
started, and offset gives the process virtual address to
start at. If the mode is PHYS_*, execution of the target is
continued at the specified address.
For modes of BREAKPOINT and WATCHPOINT, the offset specifies
the new value of the FSM state variable. This is for FSM
breakpoints and watchpoints.
Page 60
LDP Specification Control Commands
7.2 STOP Command
The STOP command is sent by the host to stop execution of a
specified object in the target. A descriptor specifies the
object. Applied to a breakpoint or watchpoint, STOP deactivates
it. The breakpoint/watchpoint may be re-activated by issuing a
START or a CONTINUE command for it.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | CONTROL | STOP |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descriptor
+-- ID --+ |
4 | Field | |
+-------------------------------+ +-+
STOP Command Format
Figure 36
STOP FIELDS:
Descriptor
The descriptor specifies the object to be stopped or
disarmed. If the mode is PROCESS_CODE, the ID specifies the
process to be stopped.
For modes of BREAKPOINT and WATCHPOINT, the specified
breakpoint or watchpoint is deactivated. It may be re-
activated by a CONTINUE or START command.
Page 61
RFC-909 July 1984
7.3 CONTINUE Command
The CONTINUE command is sent by the host to resume execution
of a specified object in the target. A descriptor specifies the
object. Applied to a breakpoint or watchpoint, CONTINUE activates
it.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | CONTROL | CONTINUE |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descriptor
+-- ID --+ |
4 | Field | |
+-------------------------------+ +-+
CONTINUE Command Format
Figure 37
CONTINUE FIELDS:
Descriptor
The descriptor specifies the object to be resumed or armed.
If the mode is PROCESS_CODE, the ID specifies the process to
be resumed.
For modes of BREAKPOINT and WATCHPOINT, the specified
breakpoint or watchpoint is armed.
7.4 STEP Command
The STEP command is sent by the host to the target. It
requests the execution of one instruction (or appropriate
operation) in the object specified by the descriptor.
Page 62
LDP Specification Control Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | CONTROL | STEP |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descriptor
+-- ID --+ |
4 | Field | |
+-------------------------------+ +-+
STEP Command Format
Figure 38
STEP FIELDS:
Descriptor
The descriptor specifies the object to be stepped. If the
mode is PROCESS_CODE, the ID specifies a process.
7.5 REPORT Command
The REPORT command is sent by the host to request a status
report on a specified target object. The status is returned in a
STATUS reply.
Page 63
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 | 10 |
+---------------+---------------+
1 | CONTROL | REPORT |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descriptor
+-- ID --+ |
4 | Field | |
+-------------------------------+ +-+
REPORT Command Format
Figure 39
REPORT FIELDS:
Descriptor
The descriptor specifies the object for which a STATUS
report is requested. For a mode of PROCESS_CODE, the ID
specifies a process. Other valid modes are PHYS_MACRO, to
query the status of the target application, and BREAKPOINT
and WATCHPOINT, to get the status of a breakpoint or
watchpoint.
7.6 STATUS Reply
The target sends a STATUS reply in response to a REPORT
command from the host. STATUS gives the state of a specified
object. For example, it may tell whether a particular target
process is running or stopped.
Page 64
LDP Specification Control 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 | CONTROL | STATUS |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | | Descriptor
+-- ID --+ |
4 | Field | |
+-------------------------------+ +-+
5 | Status |
+-------------------------------+ +-+
* |
* |
* | Other Data
+-------------------------------+ |
n | Other Data | |
+-------------------------------+ +-+
STATUS Reply Format
Figure 40
STATUS FIELDS:
Descriptor
The descriptor specifies the object whose status is being
given. If the mode is PROCESS_CODE, then the ID specifies a
process. If the mode is PHYS_MACRO, then the status is that
of the target application.
Status
The status code describes the status of the object. Status
codes are 0=STOPPED and 1=RUNNING. For breakpoints and
watchpoints, STOPPED means disarmed and RUNNING means armed.
Other Data
For breakpoints and watchpoints, Other Data consists of a
Page 65
RFC-909 July 1984
16-bit word giving the current value of the FSM state
variable.
7.7 EXCEPTION Trap
An EXCEPTION is a spontaneous message sent from the target
indicating a target-machine exception associated with a
particular object. The object is specified by an address.
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 | CONTROL | EXCEPTION |
+---------------+---------------+ +-+
2 | Mode | 0 | |
+---------------+---------------+ |
3 | | |
+-- ID --+ |
4 | Field | | Address
+-------------------------------+ |
5 | | |
+-- Offset --+ |
6 | | |
+-------------------------------+ +-+
7 | Type |
+-------------------------------+ +-+
* |
* |
* | Other Data
+-------------------------------+ |
n | Other Data | |
+-------------------------------+ +-+
EXCEPTION Format
Figure 41
EXCEPTION FIELDS:
Address
Page 66
LDP Specification Control Commands
The address specifies the object the exception is for.
Type
The type of exception. Values are target-dependent.
Other Data
Values are target-dependent.
Page 67
RFC-909 July 1984
Page 68
LDP Specification Management Commands
CHAPTER 8
Management Commands
Management commands are used to control resources in the
target machine. There are two kinds of commands: those that
interrogate the remote machine about resources, and those that
allocate and free resources. There are management commands to
create, list and delete breakpoints. All commands have
corresponding replies which include the sequence number of the
request command. Failing requests produce ERROR replies.
There are two resource allocation commands, CREATE and
DELETE, which create and delete objects in the remote machine.
There are a number of listing commands for listing a variety of
target objects -- breakpoints, watchpoints, processes, and names.
The amount of data returned by listing commands may vary in
length, depending on the state of the target. If a list is too
large to fit in a single message, the target will send it in
several list replies. A flag in each reply specifies whether
more messages are to follow.
8.1 CREATE Command
The CREATE command is sent from the host to the target to
create a target object. If the CREATE is successful, the target
returns a CREATE_DONE reply, which contains a descriptor
associated with the CREATEd object. The types of objects that
may be specified in a CREATE include breakpoints, processes,
memory objects and descriptors. All are optional except for
breakpoints.
Page 69
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 | CREATE |
+---------------+---------------+
2 | Create Type |
+---------------+---------------+ +-+
* |
* | Create
* | Arguments
+---------------+---------------+ |
n | Create Arguments | |
+---------------+---------------+ +-+
CREATE Command Format
Figure 42
CREATE FIELDS:
Create Type
The type of object to be created. Arguments vary with the
type. Currently defined types are shown in Figure 43. All
are optional except for BREAKPOINT.
Create Type | Symbol
-------------+----------------
0 BREAKPOINT
1 WATCHPOINT
2 PROCESS
3 MEMORY_OBJECT
4 DESCRIPTOR
Create Types
Figure 43
Page 70
LDP Specification Management Commands
Create Arguments
Create arguments depend on the type of object being created.
The formats for each type of object are described below.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 22 |
+---------------+---------------+
1 | MANAGEMENT | CREATE |
+---------------+---------------+
2 | BREAKPOINT |
+---------------+---------------+ +-+
3 | Mode | Mode Argument | |
+---------------+---------------+ |
4 | | |
+-- ID --+ | Create
5 | Field | | BREAKPOINT
+-------------------------------+ | Arguments
6 | | |
+-- Offset --+ |
7 | | |
+-------------------------------+ |
8 | Maximum States | |
+---------------+---------------+ |
9 | Maximum Size | |
+---------------+---------------+ |
10| Maximum Local Variables | |
+---------------+---------------+ +-+
CREATE BREAKPOINT Format
Figure 44
BREAKPOINT and WATCHPOINT
The format is the same for CREATE BREAKPOINT and CREATE
WATCHPOINT. In the following discussion, 'breakpoint' may
be taken to mean either breakpoint or watchpoint.
The address is the location where the breakpoint is to be
set. In the case of watchpoints it is the location to be
Page 71
RFC-909 July 1984
watched. Valid modes are any PHYS_* mode that addresses
macro-memory, PROCESS_CODE for breakpoints and PROCESS_DATA
for watchpoints.
'Maximum states' is the number of states the finite state
machine for this breakpoint will have. A value of zero
indicates a default breakpoint, for targets which do not
implement finite state machine (FSM) breakpoints. A default
breakpoint is the same as an FSM with one state consisting
of a STOP and a REPORT command for the process containing
the breakpoint.
'Maximum size' is the total size, in octets, of the
breakpoint data to be sent via subsequent BREAKPOINT_DATA
commands. This is the size of the data only, and does not
include the LDP command headers and breakpoint descriptors.
'Maximum local variables' is the number of 32-bit longs to
reserve for local variables for this breakpoint. Normally
this value will be zero.
PROCESS
Creates a new process. Arguments are target-dependent.
Page 72
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 | CREATE |
+---------------+---------------+
2 | MEMORY_OBJECT |
+---------------+---------------+
3 | Object Size |
+---------------+---------------+
4 | Name Size |
+-------------------------------+ +-+
5 | Name char | Name char | |
+-------------------------------+ |
* | Object
* | Name
* |
+---------------+---------------+ |
n | 0 or Name char| 0 | |
+---------------+---------------+ +-+
CREATE MEMORY_OBJECT Format
Figure 45
MEMORY_OBJECT
Creates an object of size Object Size, with the given name.
Object Size is in target dependent units. The name may be
the null string for unnamed objects. Name Size gives the
number of characters in Object Name, and must be even.
Always ends with a null octect.
DESCRIPTOR
Used for obtaining descriptors from IDs on target systems
where IDs are longer than 32 bits. There is a single
argument, Long ID, whose length is target dependent.
Page 73
RFC-909 July 1984
8.2 CREATE_DONE Reply
The target sends a CREATE_DONE reply to the host in response
to a successful CREATE command. The reply contains the sequence
number of the CREATE request, and a descriptor for the object
created. This descriptor is used by the host to specify the
object in subsequent commands referring to it. Commands which
refer to created objects include LIST_* commands, DELETE and
BREAKPOINT_DATA. For example, to delete a CREATEd object, the
host sends a DELETE command that specifies the descriptor
returned by the CREATE_DONE reply.
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 | CREATE_DONE |
+---------------+---------------+
2 | Create Sequence Number |
+---------------+---------------+ +-+
3 | Mode | Mode Argmuent | |
+---------------+---------------+ | Created
4 | | | Object
+-- ID --+ | Descriptor
5 | Field | |
+---------------+---------------+ +-+
CREATE_DONE Reply Format
Figure 46
CREATE_DONE FIELDS:
Create Sequence Number
The sequence number of the CREATE command to which this is
the reply.
Created Object Descriptor
A descriptor assigned by the target to the created object.
The contents of the descriptor fields are arbitrarily
Page 74
LDP Specification Management Commands
assigned by the target at its convenience. The host treats
the descriptor as a unitary object, used for referring to
the created object in subsequent commands.
8.3 DELETE Command
The host sends a DELETE command to remove an object created
by an earlier CREATE command. The object to be deleted is
specified with a descriptor. The descriptor is from the
CREATE_DONE reply to the original CREATE command.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 10 |
+---------------+---------------+
1 | MANAGEMENT | DELETE |
+---------------+---------------+ +-+
2 | Mode | Mode Argument | |
+---------------+---------------+ |
3 | | | Created
+-- ID --+ | Object
4 | Field | | Descriptor
+---------------+---------------+ +-+
DELETE Command Format
Figure 47
DELETE FIELDS:
Created Object Descriptor
Specifies the object to be deleted. This is the descriptor
that was returned by the target in the CREATE_DONE reply to
the original CREATE command.
Page 75
RFC-909 July 1984
8.4 DELETE_DONE Reply
The target sends a DELETE_DONE reply to the host in response
to a successful DELETE command. The reply contains the sequence
number of the DELETE request.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | MANAGEMENT | DELETE_DONE |
+---------------+---------------+
2 | Delete Sequence Number |
+---------------+---------------+
DELETE_DONE Reply Format
Figure 48
DELETE_DONE FIELDS:
Request Sequence Number
The sequence number of the DELETE command to which this is
the reply.
8.5 LIST_ADDRESSES Command
The host sends a LIST_ADDRESSES command to request a list of
valid address ranges for a specified object. The object is given
by a descriptor. Typical objects are a target process, or the
target physical machine. The target responds with an
ADDRESS_LIST reply. This command is used for obtaining the size
of dynamic address spaces and for determining dump ranges.
Page 76
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 | 10 |
+---------------+---------------+
1 | MANAGEMENT | LIST_ADDRESSES|
+---------------+---------------+ +-+
2 | Mode | Mode Argument | |
+---------------+---------------+ | Object
3 | | | Descriptor
+-- ID --+ |
4 | Field | |
+---------------+---------------+ +-+
LIST_ADDRESSES Command Format
Figure 49
LIST_ADDRESSES FIELDS:
Object Descriptor
Specifies the object whose address ranges are to be listed.
Valid modes include PHYS_MACRO, PHYS_MICRO, PROCESS_CODE,
and PROCESS_DATA.
8.6 ADDRESS_LIST Reply
The target sends an ADDRESS_LIST reply to the host in
response to a successful LIST_ADDRESSES command. The reply
contains the sequence number of the LIST_ADDRESSES request, the
descriptor of the object being listed, and a list of the valid
address ranges within the object.
Page 77
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 | ADDRESS_LIST |
+---------------+---------------+
2 | List Sequence Number |
+---------------+---------------+
3 | Flags |M| Item Count |
+---------------+---------------+
4 | |
+-- --+
5 | Descriptor |
+-- --+
6 | |
+---------------+---------------+ +-+
7 | | |
+-- First Address --+ | First
8 | | | Address
+-------------------------------+ | Range
9 | | |
+-- Last Address --+ |
10| | |
+-------------------------------+ +-+
*
*
*
+---------------+---------------+ +-+
| | |
+-- First Address --+ | Last
| | | Address
+-------------------------------+ | Range
| | |
+-- Last Address --+ |
| | |
+-------------------------------+ +-+
ADDRESS_LIST Reply Format
Figure 50
Page 78
LDP Specification Management Commands
ADDRESS_LIST FIELDS:
List Sequence Number
The sequence number of the LIST_ADDRESSES command to which
this is the reply.
Flags
If M=1, the address list is continued in one or more
subsequent ADDRESS_LIST replies. If M=0, this is the final
ADDRESS_LIST.
Item Count
The number of address ranges described in this command.
Descriptor
The descriptor of the object being listed.
Address Range
Each address range is composed of a pair of 32-bit addresses
which give the first and last addresses of the range. If