As per Relevance of the word condition, we have this rfc below:
Loader Debugger
RFC-909
Christopher
BBN Communications
Walter
BBN
July 1984
Status of This
This RFC specifies a proposed protocol for the ARPA
community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Table of
1 Introduction.......................................... 1
1.1 Purpose of This Document............................ 1
1.2 Summary of Features................................. 2
2 General Description................................... 3
2.1 Motivation.......................................... 3
2.2 Relation to Other Protocols......................... 4
2.2.1 Transport Service Requirements.................... 5
3 Protocol Operation.................................... 9
3.1 Overview............................................ 9
3.2 Session Management.................................. 9
3.3 Command Sequencing................................. 10
3.4 Data Packing and Transmission...................... 10
3.5 Implementations.................................... 12
4 Commands and Formats................................. 15
4.1 Packet Format...................................... 15
4.2 Command Format..................................... 16
4.2.1 Command Header................................... 16
4.3 Addressing......................................... 19
4.3.1 Long Address Format.............................. 20
4.3.2 Short Address Format............................. 25
5 Protocol Commands.................................... 29
5.1 HELLO Command...................................... 29
5.2 HELLO_REPLY........................................ 29
5.3 SYNCH Command...................................... 33
5.4 SYNCH_REPLY........................................ 34
5.5 ABORT Command...................................... 35
5.6 ABORT_DONE Reply................................... 35
5.7 ERROR Reply........................................ 36
5.8 ERRACK Acknowledgement............................. 39
6 Data Transfer Commands............................... 41
6.1 WRITE Command...................................... 42
6.2 READ Command....................................... 43
6.3 READ_DATA Response................................. 45
6.4 READ_DONE Reply.................................... 47
6.5 MOVE Command....................................... 48
6.6 MOVE_DATA Response................................. 50
Page
6.7 MOVE_DONE Reply.................................... 52
6.8 REPEAT_DATA........................................ 53
6.9 WRITE_MASK Command (Optional)...................... 54
7 Control Commands..................................... 59
7.1 START Command...................................... 59
7.2 STOP Command....................................... 61
7.3 CONTINUE Command................................... 62
7.4 STEP Command....................................... 62
7.5 REPORT Command..................................... 63
7.6 STATUS Reply....................................... 64
7.7 EXCEPTION Trap..................................... 66
8 Management Commands.................................. 69
8.1 CREATE Command..................................... 69
8.2 CREATE_DONE Reply.................................. 74
8.3 DELETE Command..................................... 75
8.4 DELETE_DONE Reply.................................. 76
8.5 LIST_ADDRESSES Command............................. 76
8.6 ADDRESS_LIST Reply................................. 77
8.7 LIST_BREAKPOINTS Command........................... 79
8.8 BREAKPOINT_LIST Reply.............................. 80
8.9 LIST_PROCESSES Command............................. 82
8.10 PROCESS_LIST Reply................................ 83
8.11 LIST_NAMES Command................................ 84
8.12 NAME_LIST Reply................................... 85
8.13 GET_PHYS_ADDR Command............................. 87
8.14 GOT_PHYS_ADDR Reply............................... 88
8.15 GET_OBJECT Command................................ 90
8.16 GOT_OBJECT Reply.................................. 91
9 Breakpoints and Watchpoints.......................... 93
9.1 BREAKPOINT_DATA Command............................ 95
10 Conditional Commands................................ 99
10.1 Condition Command Format......................... 100
10.2 COUNT Conditions................................. 101
10.3 CHANGED Condition................................ 102
10.4 COMPARE Condition................................ 103
10.5 TEST Condition................................... 105
11 Breakpoint Commands................................ 109
11.1 INCREMENT Command................................ 109
11.2 INC_COUNT Command................................ 110
11.3 OR Command....................................... 111
11.4 SET_PTR Command.................................. 112
11.5 SET_STATE Command................................ 113
Page
A Diagram Conventions................................. 115
B Command Summary..................................... 117
C Commands, Responses and Replies..................... 121
D Glossary............................................ 123
Page
1 Relation to Other Protocols............................ 4
2 Form of Data Exchange Between Layers................... 6
3 Packing of 16-bit Words............................... 11
4 Packing of 20-bit Words............................... 12
5 Network Packet Format................................. 15
6 LDP Command Header Format............................. 16
7 Command Classes....................................... 17
8 Command Types......................................... 18
9 Long Address Format................................... 20
10 Long Address Modes................................... 21
11 Short Address Format................................. 26
12 Short Address Modes.................................. 27
13 HELLO Command Format................................. 29
14 HELLO_REPLY Format................................... 30
15 System Types......................................... 31
16 Target Address Codes................................. 31
17 Feature Levels....................................... 32
18 Options.............................................. 33
19 SYNCH Command Format................................. 33
20 SYNCH_REPLY Format................................... 34
21 ABORT Command Format................................. 35
22 ABORT_DONE Reply Format.............................. 36
23 ERROR Reply Format................................... 37
24 ERROR Codes.......................................... 38
25 ERRACK Command Format................................ 40
26 WRITE Command Format................................. 42
27 READ Command Format.................................. 44
28 DATA Response Format................................. 46
29 READ_DONE Reply Format............................... 47
30 MOVE Command Format.................................. 49
31 MOVE_DATA Response Format............................ 51
32 MOVE_DONE Reply Format............................... 52
33 REPEAT_DATA Command Format........................... 54
34 WRITE_MASK Format.................................... 56
35 START Command Format................................. 60
36 STOP Command Format.................................. 61
37 CONTINUE Command Format.............................. 62
38 STEP Command Format.................................. 63
39 REPORT Command Format................................ 64
40 STATUS Reply Format.................................. 65
41 EXCEPTION Format..................................... 66
42 CREATE Command Format................................ 70
Page
43 Create Types......................................... 71
44 CREATE BREAKPOINT Format............................. 71
45 CREATE MEMORY_OBJECT Format.......................... 73
46 CREATE_DONE Reply Format............................. 74
47 DELETE Command Format................................ 75
48 DELETE_DONE Reply Format............................. 76
49 LIST_ADDRESSES Command Format........................ 77
50 ADDRESS_LIST Reply Format............................ 78
51 LIST_BREAKPOINTS Command Format...................... 80
52 BREAKPOINT_LIST Reply Format......................... 81
53 LIST_PROCESSES Command Format........................ 82
54 PROCESS_LIST Reply Format............................ 84
55 LIST_NAMES Command Format............................ 85
56 NAME_LIST Reply Format............................... 86
57 GET_PHYS_ADDR Command Format......................... 88
58 GOT_PHYS_ADDR Reply Format........................... 89
59 GET_OBJECT Command Format............................ 90
60 GOT_OBJECT Reply Format.............................. 91
61 Commands to Manipulate Breakpoints................... 93
62 Breakpoint Conditional Command Lists................. 95
63 BREAKPOINT_DATA Command Format....................... 96
64 Breakpoint Data Stream Format........................ 97
65 Conditional Command Summary.......................... 99
66 Condition Command Header............................ 101
67 COUNT Condition Format.............................. 101
68 CHANGED Condition................................... 102
69 COMPARE Condition................................... 104
70 TEST Condition...................................... 106
71 Breakpoint Command Summary.......................... 109
72 INCREMENT Command Format............................ 110
73 INC_COUNT Command Format............................ 111
74 OR Command Format................................... 111
75 SET_PTR Command Format.............................. 112
76 SET_STATE Command Format............................ 113
77 Sample Diagram...................................... 115
78 Command Summary..................................... 118
79 Commands, Responses and Replies..................... 122
Page
CHAPTER 1
The Loader-Debugger Protocol (LDP) is an application
protocol for loading, dumping and debugging target
from hosts in a network environment. This protocol is
to accommodate a variety of target cpu types. It provides
powerful set of debugging services. At the same time, it
structured so that a simple subset may be implemented
applications like boot loading where efficiency and space
at a premium
The authors would like to thank Dan Franklin and
Cudhea for providing many of the ideas on which this protocol
based
1.1 Purpose of This
This is a technical specification for the LDP protocol.
is intended to be comprehensive enough to be used by
of the protocol. It contains detailed descriptions of
formats and usage of over forty commands. Readers interested
an overview of LDP should read the Summary of Features, below
and skim Sections 2 through 3.1. Also see Appendix B,
Command Summary. The remainder of the document reads best
accompanied by strong coffee or tea
Page 1
RFC-909 July 1984
1.2 Summary of
LDP has the following features
o commands to perform loading, dumping and
o support for multiple connections to a single
o reliable performance in an internet
o a small protocol subset for target
o addressing modes and commands to support
machine
o breakpoints and watchpoints which run in the
machine
Page 2
LDP Specification General
CHAPTER 2
General
2.1
LDP is an application protocol that provides a set
commands used by application programs for loading, dumping
debugging target machines across a network
The goals of this protocol are shown in the following list
o The protocol should support various processor types
operating systems. Overhead and complexity should
minimized for simpler cases
o The protocol should provide support for applications
which more than one user can debug the same
machine. This implies an underlying transport
that supports multiple connections between a host-
pair
o LDP should have a minimal subset of commands for
loading and dumping. Target machine implementations
these applications are often restricted in the amount
code-space they may take. The services needed
loading and dumping should be provided in a small
easily implemented set of commands
o There should be a means for communicating exceptions
errors from the target LDP process to the host process
o LDP should allow the application to implement a full
of debugging functions without crippling the
of the target's application (i.e., PSN, PAD, gateway).
For example, a breakpoint mechanism that halts
target machine while breakpoint commands are sent
the host to the target is of limited usefulness,
the target will be unable to service the real-
Page 3
RFC-909 July 1984
demands of its application
2.2 Relation to Other
LDP is an application protocol that fits into the
internet protocol environment. Figure 1 illustrates the place
LDP in the protocol hierarchy
+------------------------------+
| LDP |
+------------------------------+
| |
| |
| |
+---------+ +---------+
| RDP | or | TCP | Transport
+---------+ +---------+
| or | |
| | |
| +--------------------+
| | Internet Protocol |
| +--------------------+
| |
+------------------------------+
| Network Access Protocol | Network
+------------------------------+
Relation to Other
Figure 1
Page 4
LDP Specification General
2.2.1 Transport Service
LDP requires that the underlying transport layer
o allow connections to be opened by specifying a
(or internet) address. Support passive and
opens
o for each connection, specify the maximum message size
o provide a mechanism for sending and receiving
over an open connection
o deliver messages reliably and in
o support multiple connections, and distinguish
associated with different connections. This is only
requirement where LDP is expected to support
users at the same time
o explictly return the outcome (success/failure) of
request (open, send, receive), and provide a means
querying the status of a connection (
message count, etc.).
Data is passed from the application program to the LDP
process in the form of commands. In the case of an LDP
process, command responses originate in LDP itself. Below LDP
the transport protocol. The Reliable Data Protocol (RDP --
RFC 908) is the recommended transport procotol. Data is
across the LDP/RDP interface in the form of messages. (TCP
be used in place of RDP, but it will be less efficient and
will require more resources to implement.) An internet
(IP) normally comes between RDP and the network layer, but
may exchange data packets directly with the network layer
Figure 2 shows the flow of data across the
interfaces
Page 5
RFC-909 July 1984
+------+
| |
|Appli-|
|cation
| |
+------+
^
Commands |
+------+
| |
| LDP |
| |
+------+
^
Messages |
+-----+
| |
| RDP |
| |
+-----+
^
Segments |
+----+
| |
| IP |
| |
+----+
^
Datagrams |
? * !
$ = ^ +
*
>
, ?
! )
* % $
Form of Data Exchange Between
Figure 2
Page 6
LDP Specification General
Page 7
RFC-909 July 1984
Page 8
LDP Specification Protocol
CHAPTER 3
Protocol
3.1
An LDP session consists of an exchange of commands
responses between an LDP user process and an LDP server process
Normally, the user process resides on a host machine (
timesharing computer used for network monitoring and control),
and the server process resides on a target machine (PSN, PAD
gateway, etc.). Throughout this document, host and target
used as synonyms for user process and server process
respectively, although in some implementations (the Butterfly
for example) this correspondence may be reversed. The
controls the session by sending commands to the target.
commands elicit responses, and all commands may elicit an
reply
The protocol contains five classes of commands: protocol
data transfer, management, control and breakpoint.
commands are used to verify the command sequencing mechanism
to handle erroneous commands. Data transfer commands involve
transfer of data from one place to another, such as for
examine/deposit, or loading. Management commands are used
creating and deleting objects (processes, breakpoints
watchpoints, etc.) in the target machine. Control commands
used to control the execution of target code and breakpoints
Breakpoint commands are used to control the execution of
inside breakpoints and watchpoints
3.2 Session
An LDP session consists of a series of commands sent from
host LDP to a target LDP, some of which may be followed
responses from the target. A session begins when a host opens
transport connection to a target listening on a well known port
LDP uses RDP port number zzz or TCP port number yyy. When
connection has been established, the host sends a HELLO command
and the target replies with a HELLO_REPLY. The HELLO_
contains parameters that describe the target's implementation
LDP, including protocol version, implementation level,
Page 9
RFC-909 July 1984
type, and address format. The session terminates when the
closes the underlying transport connection. When the
detects that the transport connection has been closed, it
deallocate any resources dedicated to the session
The target process is the passive partner in an LDP session
and it waits for the host process to terminate the session.
an implementation consideration, either LDP or the
transport protocol in the target should have a method
detecting if the host process has died. Otherwise, an
target that supported only one connection could be
useless by a host that crashed in the middle of a session.
problem of detecting half-dead connections can be avoided
taking a different tack: the target could allow new
to usurp inactive connections. A connection with no
could be declared 'dead', but would not be usurped until
connection resource was needed. However, this would
require the transport layer to support two connection channels
one to receive connection requests, and another to use for
active connection
3.3 Command
Each command sent from the host to the target has a
number. The sequence number is used by the target to refer
the command in normal replies and error replies. To save space
these numbers are not actually included in host commands
Instead, each command sent from the host is assigned an
sequence number. The sequence number starts at zero at
beginning of the LDP session and increases by one for
command sent. The host and target each keep track of the
number. The SYNCH <sequence number> command may be used by
host to synchronize the sequence number
3.4 Data Packing and
The convention for the order of data packing was chosen
its simplicity: data are packed most significant bit first,
order of increasing target address, into eight-bit octets.
octets of packed data are transmitted in sequential order
Page 10
LDP Specification Protocol
Data are always packed according to the address format
the target machine. For example, in an LDP session between
20-bit host and a 16-bit target, 16-bit words (packed
octets) are transmitted in both directions. For ease
discussion, targets are treated here as if they have
address spaces. In practice, the size of address units may
within a target -- 16-bit macromemory, 32-bit micromemory, 10-
dispatch memory, etc. Data packing between host and target
tailored to the units of the current target address space
Figures showing the packing of data for targets with
address unit sizes are given below. The order of
with respect to the diagrams is top to bottom. Bit numbering
the following diagrams refers to significance in the octet:
zero is the least significant bit in an octet. For
explanation of the bit numbering convention that applies in
rest of this document, please see Appendix A
The packing of data for targets with word lengths that
multiples of 8 is straightforward. The following
illustrates 16-bit packing
7 0
---------------------------------
Octet 0 | WORD 0 bits 15-08 |
---------------------------------
Octet 1 | WORD 0 bits 07-00 |
---------------------------------
Octet 2 | WORD 1 bits 15-08 |
---------------------------------
Octet 3 | WORD 1 bits 07-00 |
---------------------------------
*
*
*
---------------------------------
Octet 2n-1 | WORD n bits 07-00 |
---------------------------------
Packing of 16-bit
Figure 3
Page 11
RFC-909 July 1984
Packing for targets with peculiar word lengths is
complicated. For 20-bit machines, 2 words of data are
into 5 octets. When an odd number of 20-bit words
transmitted, the partially used octet is included in the
of the command, and the octet is padded to the right with zeroes
7 0
---------------------------------
Octet 0 | WORD 0 bits 19-12 |
---------------------------------
Octet 1 | WORD 0 bits 11-04 |
---------------------------------
Octet 2 | WORD 0 03-00 | WORD 1 19-16 |
---------------------------------
Octet 3 | WORD 1 bits 15-08 |
---------------------------------
Octet 4 | WORD 1 bits 07-00 |
---------------------------------
Packing of 20-bit
Figure 4
3.5
A subset of LDP commands may be implemented in targets
machine resources are limited and the full capabilities of
are not needed. There are three basic levels of
implementations: LOADER_DUMPER, BASIC_DEBUGGER
FULL_DEBUGGER. The target communicates its LDP
level to the host during session initiation. The
levels are described below
Page 12
LDP Specification Protocol
LOADER_
Used for loading/dumping of the target machine
Includes all protocol class commands and replies;
transfer commands READ, WRITE, MOVE and their responses
control command START and control reply EXCEPTION
Understands at least PHYS_MACRO and HOST addressing modes
others if desired
BASIC_
Implements LOADER_DUMPER commands, all control commands
all addressing modes appropriate to the target machine,
does not have finite state machine (FSM) breakpoints
watchpoints. Default breakpoints are implemented.
target understands long addressing mode
FULL_
Implements all commands and addressing modes appropriate
the target machine, and includes breakpoint commands
conditional commands and BREAKPOINT_DATA. Watchpoints
optional
Page 13
RFC-909 July 1984
Page 14
LDP Specification Commands and
CHAPTER 4
Commands and
4.1 Packet
LDP commands are enclosed in RDP transport messages. An
message may contain more than one command, but each command
fit entirely within a single message. Network packets
LDP commands have the format shown in Figure 5.
+----------------+
| Local Network |
| Header(s) |
+----------------+
| IP Header |
+----------------+
| RDP Header |
+----------------+ +-+
| LDP Command | |
| Header | |
+----------------+ |
| Optional | |
. LDP . | LDP
. Data . |
| | |
+----------------+ |
| LDP Padding | |
+----------------+ +-+
| Additional |
. LDP .
. Commands .
. .
+----------------+
Network Packet
Figure 5
Page 15
RFC-909 July 1984
4.2 Command
LDP commands consist of a standard two-word header
optionally by additional data. To facilitate parsing of multi
command messages, all commands contain an even number of octets
Commands that contain an odd number of data octets must be
with a null octet
The commands defined by the LDP specification are
to be of universal application to provide a common basis for
implementations. Command class and type codes from 0 to 63.
reserved by the protocol. Codes above 63. are available for
implementation of target-specific commands
4.2.1 Command
LDP commands begin with a fixed length header. The
specifies the type of command and its length in octets
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length (octets) |
+---------------+---------------+
1 | Command Class | Command Type |
+---------------+---------------+
LDP Command Header
Figure 6
HEADER FIELDS
Command
The command length gives the total number of octets in
command, including the length field and data, and
padding
Command
Command
Page 16
LDP Specification Commands and
The command class and type together specify a
command. The class selects one of six command categories
and the type gives the command within that category.
codes are decimal. The symbols given in Figures 7 and 8
command classes and types are used in the remainder of
document for reference
The command classes that have been defined are
Command Class |
----------------+-----------
1 |
2 | DATA_
3 |
4 |
5 |
6 |
7 - 63 | <reserved
Command
Figure 7
Command type codes are assigned in order of
frequency of use. Commands and their responses/replies
numbered sequentially. The command types, ordered
command class, are
Page 17
RFC-909 July 1984
Command Class | Command Type |
----------------+---------------+----------
PROTOCOL | 1 |
| 2 | HELLO_
| 3 |
| 4 | SYNCH_
| 5 |
| 6 |
| 7 |
| 8 | ABORT_
| 9 - 63 | <reserved
| |
DATA_TRANSFER | 1 |
| 2 |
| 3 | READ_
| 4 | READ_
| 5 |
| 6 | MOVE_
| 7 | MOVE_
| 8 | REPEAT_
| 9 | BREAKPOINT_
| 10 | WRITE_
| 11 - 63 | <reserved
| |
CONTROL | 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
| 7 |
| 8 - 63 | <reserved
| |
MANAGEMENT | 1 |
| 2 | CREATE_
| 3 |
| 4 | DELETE_
| 5 | LIST_
| 6 | ADDRESS_
| 7 | GET_PHYS_
| 8 | GOT_PHYS_
| 9 | GET_
| 10 | GOT_
| 11 | LIST_
| 12 | BREAKPOINT_
Page 18
LDP Specification Commands and
| 13 | LIST_
| 14 | NAME_
| 15 | LIST_
| 16 | PROCESS_
| 17 - 63 | <reserved
| |
BREAKPOINT | 1 |
| 2 | INC_
| 3 |
| 4 | SET_
| 5 | SET_
| 6 - 63 | <reserved
| |
CONDITION | 1 |
| 2 |
| 3 | COUNT_
| 4 | COUNT_
| 5 | COUNT_
| 6 |
| 7 - 63 | <reserved
Command
Figure 8
4.3
Addresses are used in LDP commands to refer to
locations, processes, buffers, breakpoints and other entities
Many of these entities are machine-dependent; some machines
named objects, some machines have multiple address spaces,
size of address spaces varies, etc. The format for
addresses needs to be general enough to handle all of
cases. This speaks for a large, hierarchically
address format. However, the disadvantage of a large format
that it imposes extra overhead on communication with targets
have simpler address schemes
LDP resolves this conflict by employing two address formats
a short three-word format for addressing simpler targets, and
long five-word format for others. Each target LDP is required
implement at least one of these formats. At the start of an
session, the target specifies the address format(s) it uses
Page 19
RFC-909 July 1984
the Flag field of the HELLO_REPLY message. In each address,
first bit of the mode octet is a format flag: 0 indicates
address format, and 1 indicates SHORT format
4.3.1 Long Address
The long address format is five words long and consists of
three-word address descriptor and a two-word offset (see
9). The descriptor specifies an address space to which the
is applied. The descriptor is subdivided into several fields,
described below. The structuring of the descriptor is
to support complex addressing modes. For example, on
with multiple processes, descriptors may reference
addresses, registers, and other entities within a
process
The addressing modes defined below are intended as a base
which target-specific modes may be added. Modes up to 63.
reserved by the protocol. The range 64. to 127. may be used
target-specific address modes
Long Format - Format bit is LONG=0
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+ +-+
|0| Mode | Mode Arg | |
+-------------------------------+ |
| (31-16) | |
+---- ID ---+ |
| (15-0) | |
+-------------------------------+ +-+
| (31-16) | |
+---- Offset ---+ |
| (15-0) | |
+-------------------------------+ +-+
Long Address
Figure 9
LONG ADDRESS FIELDS
Page 20
LDP Specification Commands and
The address mode identifies the type of address space
referenced. The mode is qualified by the mode argument
the ID field. Implementation of modes other than
and host is machine-dependent. Currently defined modes
the address space they reference are shown in Figure 10.
Mode | Symbol | Address
-----+----------------------+---------------------------
0 HOST
1 PHYS_MACRO
2 PHYS_MICRO
3 PHYS_I/O I/O
4 PHYS_MACRO_PTR Macro contains a
5 PHYS_REG
6 PHYS_REG_OFFSET Register plus
7 PHYS_REG_INDIRECT Register contains
of a
8 PROCESS_CODE Process code
9 PROCESS_DATA Process data
10 PROCESS_DATA_PTR Process data contains a
11 PROCESS_REG Process virtual
12 PROCESS_REG_OFFSET Process register plus
13 PROCESS_REG_INDIRECT Process register
address of a
14 OBJECT_OFFSET Memory object (queue, pool
15 OBJECT_HEADER System header for an
16 BREAKPOINT
17 WATCHPOINT
18 BPT_PTR_OFFSET Breakpoint ptr plus
19 BPT_PTR_INDIRECT Breakpoint ptr plus
gives address of a
20 - <reserved
63
Long Address
Figure 10
Mode
Page 21
RFC-909 July 1984
Provides a numeric argument to the mode field.
the register in physical and process REG and REG_
modes
ID
Identifies a particular process, buffer or object
The offset into the linear address space defined by
mode. The size of the machine word determines the number
significant bits in the offset. Likewise, the
units of the target are the units of the offset
The interpretation of the mode argument, ID field and offset
each address mode is given below
The ID and offset fields are numbers assigned arbitrarily
the host side of the debugger. These numbers are used
MOVE and MOVE_DATA messages. MOVE_DATA responses
this mode as the destination are sent by the target to
host. This may occur in debugging when data is sent to
host from the target breakpoint
PHYS_
The offset contains the 32-bit physical address of
location in macromemory. The mode argument and ID field
not used. For example, mode=PHYS_MACRO and offset=1000
specifies location 1000 in physical memory
PHYS_
Like PHYS_MACRO, but the location is in micromemory
PHYS_I/
Like PHYS_MACRO, but the location is in I/O space
PHYS_MACRO_
The offset contains the address of a pointer in macromemory
The location pointed to (the effective address) is also
macromemory. The mode argument and ID field are unused
Page 22
LDP Specification Commands and
PHYS_
The mode argument gives the physical register. If
register is used by the LDP target process, then the
copy from the previous context is used. This
applies to PHYS_REG_OFFSET mode as well. The ID field
not used
PHYS_REG_
The offset is added to the contents of a register given
the mode argument. The result is used as a physical
in macromemory. ID is unused
PHYS_REG_
The register specified in the mode arg contains the
of a pointer in macromemory. The effective address is
macromemory location specified in the pointer, plus
offset. The ID field is unused
PROCESS_
The ID is a process ID, the offset is into the code
for this process. Mode argument is not used
PROCESS_
The ID is a process ID, the offset is into the data
for this process. Mode argument is not used. On
that do not distinguish between code and data space,
two modes are equivalent, and reference the virtual
space of the process
PROCESS_DATA_
The offset contains the address of a pointer in the
space of the process specified by the ID. The
pointed to (the effective address) is also in the
space. The mode argument is not used
PROCESS_
Accesses the registers (and other system data) of
process given by the ID field. Mode argument 0 starts
registers. After the registers, the mode argument is
offset into the system area for the process
Page 23
RFC-909 July 1984
PROCESS_REG_
The offset plus the contents of the register given in
mode argument specifies a location in the data space of
process specified by the ID
PROCESS_REG_
The register specified in the mode arg contains the
of a pointer in the data space of the process given by
ID. The effective address is the location in process
space specified in the pointer, plus the offset
OBJECT_OFFSET (optional
The offset is into the memory space defined by the object
in ID. Recommended for remote control of
segments
OBJECT_HEADER (optional
The offset is into the system header for the
specified by the ID. Intended for use with the Butterfly
The descriptor specifies a breakpoint. The offset is
used, this type is only used in descriptors referring
breakpoints. (See Breakpoints and Watchpoints, below,
an explanation of breakpoint descriptors.)
The descriptor specifies a watchpoint. The offset is
used, this type is only used in descriptors referring
watchpoints. (See Breakpoints and Watchpoints, below,
an explanation of watchpoint descriptors).
BPT_PTR_
For this mode and BPT_PTR_INDIRECT, the mode
specifies one of two breakpoint pointer variables local
the breakpoint in which this address occurs. These
and the SET_PTR command which manipulates them provide
an arbitrary amount of address indirection. They
intended for use in traversing data structures: for example
chasing queues. In BPT_PTR_OFFSET, the offset is added
Page 24
LDP Specification Commands and
the pointer variable to give the effective address.
targets which support multiple processes, the location is
the data space of the process given by the ID. Otherwise
the location is a physical address in macro-memory
BPT_PTR.* modes are valid only in breakpoints
watchpoints
BPT_PTR_
Like BPT_PTR_OFFSET, except that it uses one more level
indirection. The pointer variable given by the
argument plus the offset specify an address which points
the effective address. See the description
BPT_PTR_OFFSET for a discussion of usage, limitations
address space
4.3.2 Short Address
The short address format is intended for use
implementations where protocol overhead must be minimized.
format is a subset of the long address format: it contains
same fields except for the ID field. Therefore, the
addressing format supports only HOST and PHYS_* address modes
Only the LOADER_DUMPER implementation level commands may be
with the short addressing format. The short address format
three words long, consisting of a 16-bit word describing
address space, and a 32-bit offset
Page 25
RFC-909 July 1984
Short Format - Format bit is SHORT=1
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-------------------------------+
|1| Mode | Mode Argument |
+-------------------------------+ +-+
| (31-16) | |
+---- Offset ---+ |
| (15-0) | |
+-------------------------------+ +-+
Short Address
Figure 11
SHORT ADDRESS FIELDS
The high-order bit is 1, indicating the short
format. A list of the address modes supported is
below. The interpretation of the remaining fields is
described above for the long addressing format
Page 26
LDP Specification Commands and
Mode | Symbol | Address
-----+--------------------+---------------------------
0 HOST
1 PHYS_MACRO Macro-
2 PHYS_MICRO Micro-
3 PHYS_I/O I/O
4 PHYS_MACRO_PTR Macro contains a
5 PHYS_REG
6 PHYS_REG_OFFSET Register plus
7 PHYS_REG_INDIRECT Register contains
of a
8 -
32 <reserved
Short Address
Figure 12
Page 27
RFC-909 July 1984
Page 28
LDP Specification Protocol
CHAPTER 5
Protocol
Protocol commands are used for error handling,
synchronizing the command sequence number, and for
protocol implementation parameters. Every protocol command has
corresponding reply. All protocol commands are sent from
host to the target, with replies flowing in the
direction
5.1 HELLO
The HELLO command is sent by the host to signal the start
an LDP session. The target responds with HELLO_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 | HELLO |
+---------------+---------------+
HELLO Command
Figure 13
5.2 HELLO_
A HELLO_REPLY is sent by the target in response to the
command at the start of an LDP session. This reply is used
inform the host about the target's implementation of LDP
Page 29
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 | PROTOCOL | HELLO_REPLY |
+---------------+---------------+
2 | LDP Version | System Type |
+---------------+---------------+
3 | Options |W|S| Implementation
+---------------+---------------+
4 | Address Code | Reserved |
+---------------+---------------+
HELLO_REPLY
Figure 14
HELLO_REPLY FIELDS
LDP
The target's LDP protocol version. If the
host protocol version does not agree with the target'
protocol version, the host may terminate the session,
may continue it, at the discretion of the implementor.
current version number is 2.
System
The type of system running on the target. This is used as
check against what the host thinks the target is. The
is expected to have a table of target system types
information about target address spaces, target-
commands and addressing modes, and so forth
Currently defined system types are shown in Figure 15.
list includes some systems normally thought of as 'hosts
(e.g. C70, VAX), for implementations where targets
initiate and direct a load of themselves
Page 30
LDP Specification Protocol
Code | System |
--------+---------------+---------------------------
1 C30_16_BIT BBN 16-bit C30
2 C30_20_BIT BBN 20-bit C30
3 H316 Honeywell-316
4 BUTTERFLY BBN
5 PDP-11 DEC PDP-11
6 C10 BBN C10
7 C50 BBN C50
8 PLURIBUS BBN
9 C70 BBN C70
10 VAX DEC
11 MACINTOSH Apple
System
Figure 15
Address
The address code indicates which LDP address format(s)
target is prepared to use. Address codes are show in
16.
Address Code | Symbol |
--------------+---------------+-----------------------------
1 LONG_ADDRESS Five word address format
Supports all address
and commands
2 SHORT_ADDRESS Three word address format
Supports only physical
host address modes.
the LOADER_DUMPER set
commands are supported
Target Address
Figure 16
Page 31
RFC-909 July 1984
The implementation level specifies which features
the protocol are implemented in the target. There
three levels of protocol implementation. These levels
intended to correspond to the three most likely
of LDP: simple loading and dumping, basic debugging,
full debugging. (Please see Implementations, above, for
detailed description of implementation levels.) There
are also several optional features that are not included
any particular level
Implementation levels are cumulative, that is, each
level includes the features of all previous levels.
levels are shown in Figure 17.
Feature Level | Symbol |
--------------+---------------+-----------------------------
1 LOADER_DUMPER Loader/dumper subset of
2 BASIC_DEBUGGER Control commands,
3 FULL_DEBUGGER FSM
Feature
Figure 17
The options field (see Figure 18) is an eight-bit
field. Bit flags are used to indicate if the target
implemented particular optional commands. Not all
commands are referenced in this field. Commands
implementation depends on target machine features
omitted. The LDP application is expected to 'know'
target features that are not intrinsic to the protocol
Examples of target-dependent commands are commands
refer to named objects (CREATE, LIST_NAMES).
Page 32
LDP Specification Protocol
Mask | Symbol |
------+-------------+---------------+-----------------
1 STEP The STEP command is
2 WATCHPOINTS Watchpoints are
Figure 18
5.3 SYNCH
The SYNCH command is sent by the host to the target.
target responds with a SYNCH_REPLY. The SYNCH - SYNCH_
exchange serves two functions: it synchronizes the host-to-
implicit sequence number and acts as a cumulative
of the receipt and execution of all host commands up to
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
Figure 19
SYNCH FIELDS
Sequence
Page 33
RFC-909 July 1984
The sequence number of this command. If this is not
the target is expecting, the target will reset to it
respond with an ERROR reply
5.4 SYNCH_
A SYNCH_REPLY is sent by the target in reponse to a
SYNCH command. A SYNCH command is valid if its sequence
agrees with the sequence number the target is expecting
Otherwise, the target will reset its sequence number to the
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
Figure 20
SYNCH_REPLY FIELDS
Sequence
The sequence number of the SYNCH command to which
SYNCH_REPLY is the response
Page 34
LDP Specification Protocol
5.5 ABORT
The ABORT command is sent from the host to abort all
operations at the target. The target responds with ABORT_DONE
This is primarily intended to stop large data transfers from
target. A likely application would be during a debugging
when the user types an interrupt to abort a large printout
data from the target. The ABORT command has no effect on
breakpoints or watchpoints that may be enabled in the target
As a practical matter, the ABORT command may be difficult
implement on some targets. Its ability to interrupt
processing on the target depends on the target being able to
ahead at incoming commands and receive an out-of-band signal
the host. However, the effect of an ABORT may be achieved
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
Figure 21
5.6 ABORT_DONE
The ABORT_DONE reply is sent from the target to the host
response to an ABORT command. This indicates that the target
terminated all operations that were pending when the
command was received. The sequence number of the ABORT
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
Figure 22
ABORT_DONE FIELDS
Sequence
The sequence number of the ABORT command that elicited
reply. This enables the host to distinguish
replies to multiple aborts
5.7 ERROR
The ERROR reply is sent by the target in response to a
command. The ERROR reply gives the sequence number of
offending command and a reason code. The target ignores
commands until an ERRACK command is received. The reason
ignoring commands is that the proper operation of
commands may be predicated on the execution of the
command
Page 36
LDP Specification Protocol
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
Figure 23
ERROR Reply FIELDS
Command Sequence
The implicit sequence number of the erroneous command
Error
A code specifying what error has taken place. The
defined codes are shown in Figure 24.
Page 37
RFC-909 July 1984
Error Code |
-----------+------------------------
1 BAD_
2 BAD_ADDRESS_
3 BAD_ADDRESS_
4 BAD_ADDRESS_
5 BAD_CREATE_
6 NO_
7 NO_
8 OUT_OF_
9 IN_
ERROR
Figure 24
An explanation of each of these error codes follows
BAD_
The command was not meaningful to the target machine
This includes commands that are valid but
in this target. Also, the command was not valid
this context. For example, a command given by the
that is only legal in a breakpoint (e.g. IF
SET_STATE).
BAD_ADDRESS_MODE
The mode of an address given in the command is
meaningful to this target system. For example,
PROCESS address mode on a target that does not
multi-processing
BAD_ADDRESS_ID
The ID field of an address didn't correspond to
appropriate thing. For example, for a PROCESS
mode, the ID of a non-existent process
BAD_ADDRESS_OFFSET
The offset field of the address was outside the
range for the thing addressed. For example, an
of 200,000 in PHYS_MACRO mode on a target with 64K
Page 38
LDP Specification Protocol
macro-memory
BAD_CREATE_
The object type in a CREATE command was unknown
NO_
A CREATE command failed due to lack of
resources
NO_
A GET_OBJECT command failed to find the named object
OUT_OF_
The sequence number of the SYNCH command was
expected by the target. The target has
to it
IN_BREAKPOINT <breakpoint-descriptor> <breakpoint-sequence#>
[<optional-info>]
An error occurred within a breakpoint command list
The given 16-bit sequence-number refers to the
number of the CREATE command that created
breakpoint, while breakpoint-sequence# refers to
sequence number of the command within the
given by <breakpoint-descriptor>.
5.8 ERRACK
An ERRACK is sent by the host in response to an
reply from the target. The ERRACK is used to acknowledge
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
Figure 25
Page 40
LDP Specification Data Transfer
CHAPTER 6
Data Transfer
Data transfer commands transfer data between the host
the target. These commands are used for loading and dumping
target, and examining and depositing locations on the target
The READ command reads data from the target, the MOVE
moves data within the target or from the target to
entity, and the WRITE command writes data to the target
REPEAT_DATA makes copies of a pattern to the target -- it
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
target address. In writes to the target, this is used as
destination of the data. In reads from the target, the
address is used by the host to identify where in the target
data came from. In addition, the MOVE command may contain
'host' address as its destination; this permits the host
further discriminate between possible sources of data from
target -- from different breakpoints, debugging windows, etc
A read request to the target may generate one or
response messages. In particular, responses to requests
large amounts of data -- core dumps, for example -- must
broken up into multiple messages, if the block of data
plus the LDP header exceeds the transport layer message size
In commands which contain data (WRITE, READ_DATA, MOVE_
and REPEAT_DATA), if there are an odd number of data octets,
a null octet is appended. This is so that the next command
the message, if any, will begin on an even octet. The
length is the sum of the number of octets in the command
and the number of octets of data, excluding the null octet,
any
The addressing formats which may be used with data
commands are specified for each LDP session at the start of
session by the target in the HELLO_REPLY response. See
section entitled 'Addressing', above, for a description of
addressing formats and modes. In the command diagrams
below, the short addressing format is illustrated. For
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
The WRITE command is used to send octets of data from
host to the target. This command specifies the address in
target where the data is to be stored, followed by a stream
data octets. If the data stream contains an odd number
octets, then a null octet is appended so that the next command
if any, will begin on an even octet. Since LDP must
message size limitations imposed by the underlying
layer, a single logical write may need to be broken up
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
Figure 26
Page 42
LDP Specification Data Transfer
WRITE FIELDS
Command
The command length gives the number of octets in
command, including data octets, but excluding the
octet, if any
Target Start
This is the address to begin storing data in the target
The length of the data to be stored may be inferred by
target from the command length. An illegal address or
will generate an ERROR reply
Data
Octets of data to be stored in the target. Data are
according to the packing convention described above.
with a null octet if there are an odd number of data octets
6.2 READ
The host uses the READ command to ask the target
send back a contiguous block of data. The data is specified
a target 