RFC 0909
Loader Debugger Protocol
Pages: 135
Experimental
Experimental
Part 2 of 4 – Pages 35 to 69
Mask | Symbol | Description
------+-------------+---------------+-----------------
1 STEP The STEP command is implemented
2 WATCHPOINTS Watchpoints are implemented
Options
Figure 18
5.3 SYNCH Command
The SYNCH command is sent by the host to the target. The
target responds with a SYNCH_REPLY. The SYNCH - SYNCH_REPLY
exchange serves two functions: it synchronizes the host-to-target
implicit sequence number and acts as a cumulative acknowledgement
of the receipt and execution of all host commands up to the
SYNCH.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | PROTOCOL | SYNCH |
+---------------+---------------+
2 | Sequence Number |
+---------------+---------------+
SYNCH Command Format
Figure 19
SYNCH FIELDS:
Sequence Number
The sequence number of this command. If this is not what
the target is expecting, the target will reset to it and
respond with an ERROR reply.
5.4 SYNCH_REPLY
A SYNCH_REPLY is sent by the target in reponse to a valid
SYNCH command. A SYNCH command is valid if its sequence number
agrees with the sequence number the target is expecting.
Otherwise, the target will reset its sequence number to the SYNCH
command and send an ERROR reply.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | PROTOCOL | SYNCH_REPLY |
+---------------+---------------+
2 | Sequence Number |
+---------------+---------------+
SYNCH_REPLY Format
Figure 20
SYNCH_REPLY FIELDS:
Sequence Number
The sequence number of the SYNCH command to which this
SYNCH_REPLY is the response.
5.5 ABORT Command
The ABORT command is sent from the host to abort all pending
operations at the target. The target responds with ABORT_DONE.
This is primarily intended to stop large data transfers from the
target. A likely application would be during a debugging session
when the user types an interrupt to abort a large printout of
data from the target. The ABORT command has no effect on any
breakpoints or watchpoints that may be enabled in the target.
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.
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.
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.
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
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.
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
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,
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
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.
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
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.
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
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.
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.
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,
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.
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
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.
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
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
the start and the end of the modification.
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
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.
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.
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.
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.
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.
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.
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.
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
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
The address specifies the object the exception is for.
Type
The type of exception. Values are target-dependent.
Other Data
Values are target-dependent.
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.
(next page on part 3)