|
|
|
|
|
|
IETF RFC 909
Loader Debugger Protocol
Last modified on Wednesday, September 23rd, 1992
 Permanent link to RFC 909
 Search GitHub Wiki for RFC 909
 Show other RFCs mentioning RFC 909
Loader Debugger Protocol
RFC 909
Christopher Welles
BBN Communications Corporation
Walter Milliken
BBN Laboratories
July 1984
 Status of This Memo
This RFC specifies a proposed protocol for the ARPA Internet
community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Table of Contents
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 i
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 ii
A Diagram Conventions................................. 115
B Command Summary..................................... 117
C Commands, Responses and Replies..................... 121
D Glossary............................................ 123
Page iii
FIGURES
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 iv
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 v
CHAPTER 1
Introduction
The Loader-Debugger Protocol (LDP) is an application layer
protocol for loading, dumping and debugging target machines
from hosts in a network environment. This protocol is designed
to accommodate a variety of target cpu types. It provides a
powerful set of debugging services. At the same time, it is
structured so that a simple subset may be implemented in
applications like boot loading where efficiency and space are
at a premium.
The authors would like to thank Dan Franklin and Peter
Cudhea for providing many of the ideas on which this protocol is
based.
1.1 Purpose of This Document
This is a technical specification for the LDP protocol. It
is intended to be comprehensive enough to be used by implementors
of the protocol. It contains detailed descriptions of the
formats and usage of over forty commands. Readers interested in
an overview of LDP should read the Summary of Features, below,
and skim Sections 2 through 3.1. Also see Appendix B, the
Command Summary. The remainder of the document reads best when
accompanied by strong coffee or tea.
Page 1
RFC 909 July 1984
1.2 Summary of Features
LDP has the following features:
o commands to perform loading, dumping and debugging
o support for multiple connections to a single target
o reliable performance in an internet environment
o a small protocol subset for target loaders
o addressing modes and commands to support multiple
machine types
o breakpoints and watchpoints which run in the target
machine.
Page 2
LDP Specification General Description
CHAPTER 2
General Description
2.1 Motivation
LDP is an application protocol that provides a set of
commands used by application programs for loading, dumping and
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 and
operating systems. Overhead and complexity should be
minimized for simpler cases.
o The protocol should provide support for applications in
which more than one user can debug the same target
machine. This implies an underlying transport mechanism
that supports multiple connections between a host-target
pair.
o LDP should have a minimal subset of commands for boot
loading and dumping. Target machine implementations of
these applications are often restricted in the amount of
code-space they may take. The services needed for
loading and dumping should be provided in a small,
easily implemented set of commands.
o There should be a means for communicating exceptions and
errors from the target LDP process to the host process.
o LDP should allow the application to implement a full set
of debugging functions without crippling the performance
of the target's application (i.e., PSN, PAD, gateway).
For example, a breakpoint mechanism that halts the
target machine while breakpoint commands are sent from
the host to the target is of limited usefulness, since
the target will be unable to service the real-time
Page 3
RFC 909 July 1984
demands of its application.
2.2 Relation to Other Protocols
LDP is an application protocol that fits into the layered
internet protocol environment. Figure 1 illustrates the place of
LDP in the protocol hierarchy.
+------------------------------+
| LDP | Application
+------------------------------+ Layer
| |
| |
| |
+---------+ +---------+
| RDP | or | TCP | Transport Layer
+---------+ +---------+
| or | |
| | |
| +--------------------+
| | Internet Protocol | Internetwork
| +--------------------+ Layer
| |
+------------------------------+
| Network Access Protocol | Network Layer
+------------------------------+
Relation to Other Protocols
Figure 1
Page 4
LDP Specification General Description
2.2.1 Transport Service Requirements
LDP requires that the underlying transport layer:
o allow connections to be opened by specifying a network
(or internet) address. Support passive and active
opens.
o for each connection, specify the maximum message size.
o provide a mechanism for sending and receiving messages
over an open connection.
o deliver messages reliably and in sequence
o support multiple connections, and distinguish messages
associated with different connections. This is only a
requirement where LDP is expected to support several
users at the same time.
o explictly return the outcome (success/failure) of each
request (open, send, receive), and provide a means of
querying the status of a connection (unacknowledged
message count, etc.).
Data is passed from the application program to the LDP user
process in the form of commands. In the case of an LDP server
process, command responses originate in LDP itself. Below LDP is
the transport protocol. The Reliable Data Protocol (RDP --
RFC 908) is the recommended transport procotol. Data is passed
across the LDP/RDP interface in the form of messages. (TCP may
be used in place of RDP, but it will be less efficient and it
will require more resources to implement.) An internet layer
(IP) normally comes between RDP and the network layer, but RDP
may exchange data packets directly with the network layer.
Figure 2 shows the flow of data across the protocol
interfaces:
Page 5
RFC 909 July 1984
+------+
| |
|Appli-|
|cation|
| |
+------+
^
Commands |
V
+------+
| |
| LDP |
| |
+------+
^
Messages |
V
+-----+
| |
| RDP |
| |
+-----+
^
Segments |
V
+----+
| |
| IP |
| |
+----+
^
Datagrams |
V
? * !
$ = ^ +
*
> Internet
, ?
! )
* % $
Form of Data Exchange Between Layers
Figure 2
Page 6
LDP Specification General Description
Page 7
RFC 909 July 1984
Page 8
LDP Specification Protocol Operation
CHAPTER 3
Protocol Operation
3.1 Overview
An LDP session consists of an exchange of commands and
responses between an LDP user process and an LDP server process.
Normally, the user process resides on a host machine (a
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 are
used as synonyms for user process and server process,
respectively, although in some implementations (the Butterfly,
for example) this correspondence may be reversed. The host
controls the session by sending commands to the target. Some
commands elicit responses, and all commands may elicit an error
reply.
The protocol contains five classes of commands: protocol,
data transfer, management, control and breakpoint. Protocol
commands are used to verify the command sequencing mechanism and
to handle erroneous commands. Data transfer commands involve the
transfer of data from one place to another, such as for memory
examine/deposit, or loading. Management commands are used for
creating and deleting objects (processes, breakpoints,
watchpoints, etc.) in the target machine. Control commands are
used to control the execution of target code and breakpoints.
Breakpoint commands are used to control the execution of commands
inside breakpoints and watchpoints.
3.2 Session Management
An LDP session consists of a series of commands sent from a
host LDP to a target LDP, some of which may be followed by
responses from the target. A session begins when a host opens a
transport connection to a target listening on a well known port.
LDP uses RDP port number zzz or TCP port number yyy. When the
connection has been established, the host sends a HELLO command,
and the target replies with a HELLO_REPLY. The HELLO_REPLY
contains parameters that describe the target's implementation of
LDP, including protocol version, implementation level, system
Page 9
RFC 909 July 1984
type, and address format. The session terminates when the host
closes the underlying transport connection. When the target
detects that the transport connection has been closed, it should
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. As
an implementation consideration, either LDP or the underlying
transport protocol in the target should have a method for
detecting if the host process has died. Otherwise, an LDP
target that supported only one connection could be rendered
useless by a host that crashed in the middle of a session. The
problem of detecting half-dead connections can be avoided by
taking a different tack: the target could allow new connections
to usurp inactive connections. A connection with no activity
could be declared 'dead', but would not be usurped until the
connection resource was needed. However, this would still
require the transport layer to support two connection channels:
one to receive connection requests, and another to use for an
active connection.
3.3 Command Sequencing
Each command sent from the host to the target has a sequence
number. The sequence number is used by the target to refer to
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 implicit
sequence number. The sequence number starts at zero at the
beginning of the LDP session and increases by one for each
command sent. The host and target each keep track of the current
number. The SYNCH <sequence number> command may be used by the
host to synchronize the sequence number.
3.4 Data Packing and Transmission
The convention for the order of data packing was chosen for
its simplicity: data are packed most significant bit first, in
order of increasing target address, into eight-bit octets. The
octets of packed data are transmitted in sequential order.
Page 10
LDP Specification Protocol Operation
Data are always packed according to the address format of
the target machine. For example, in an LDP session between a
20-bit host and a 16-bit target, 16-bit words (packed into
octets) are transmitted in both directions. For ease of
discussion, targets are treated here as if they have uniform
address spaces. In practice, the size of address units may vary
within a target -- 16-bit macromemory, 32-bit micromemory, 10-bit
dispatch memory, etc. Data packing between host and target is
tailored to the units of the current target address space.
Figures showing the packing of data for targets with various
address unit sizes are given below. The order of transmission
with respect to the diagrams is top to bottom. Bit numbering in
the following diagrams refers to significance in the octet: bit
zero is the least significant bit in an octet. For an
explanation of the bit numbering convention that applies in the
rest of this document, please see Appendix A.
The packing of data for targets with word lengths that are
multiples of 8 is straightforward. The following diagram
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 Words
Figure 3
Page 11
RFC 909 July 1984
Packing for targets with peculiar word lengths is more
complicated. For 20-bit machines, 2 words of data are packed
into 5 octets. When an odd number of 20-bit words are
transmitted, the partially used octet is included in the length
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 Words
Figure 4
3.5 Implementations
A subset of LDP commands may be implemented in targets where
machine resources are limited and the full capabilities of LDP
are not needed. There are three basic levels of target
implementations: LOADER_DUMPER, BASIC_DEBUGGER and
FULL_DEBUGGER. The target communicates its LDP implementation
level to the host during session initiation. The implementation
levels are described below:
Page 12
LDP Specification Protocol Operation
LOADER_DUMPER
Used for loading/dumping of the target machine.
Includes all protocol class commands and replies; data
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_DEBUGGER
Implements LOADER_DUMPER commands, all control commands,
all addressing modes appropriate to the target machine, but
does not have finite state machine (FSM) breakpoints or
watchpoints. Default breakpoints are implemented. The
target understands long addressing mode.
FULL_DEBUGGER
Implements all commands and addressing modes appropriate to
the target machine, and includes breakpoint commands,
conditional commands and BREAKPOINT_DATA. Watchpoints are
optional.
Page 13
RFC 909 July 1984
Page 14
LDP Specification Commands and Formats
CHAPTER 4
Commands and Formats
4.1 Packet Format
LDP commands are enclosed in RDP transport messages. An RDP
message may contain more than one command, but each command must
fit entirely within a single message. Network packets containing
LDP commands have the format shown in Figure 5.
+----------------+
| Local Network |
| Header(s) |
+----------------+
| IP Header |
+----------------+
| RDP Header |
+----------------+ +-+
| LDP Command | |
| Header | |
+----------------+ |
| Optional | |
. LDP . | LDP Command
. Data . | Format
| | |
+----------------+ |
| LDP Padding | |
+----------------+ +-+
| Additional |
. LDP .
. Commands .
. .
+----------------+
Network Packet Format
Figure 5
Page 15
RFC 909 July 1984
4.2 Command Format
LDP commands consist of a standard two-word header followed
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 padded
with a null octet.
The commands defined by the LDP specification are intended
to be of universal application to provide a common basis for all
implementations. Command class and type codes from 0 to 63. are
reserved by the protocol. Codes above 63. are available for the
implementation of target-specific commands.
4.2.1 Command Header
LDP commands begin with a fixed length header. The header
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 Format
Figure 6
HEADER FIELDS:
Command Length
The command length gives the total number of octets in the
command, including the length field and data, and excluding
padding.
Command Class
Command Type
Page 16
LDP Specification Commands and Formats
The command class and type together specify a particular
command. The class selects one of six command categories,
and the type gives the command within that category. All
codes are decimal. The symbols given in Figures 7 and 8 for
command classes and types are used in the remainder of this
document for reference.
The command classes that have been defined are:
Command Class | Symbol
----------------+-----------
1 | PROTOCOL
2 | DATA_TRANSFER
3 | CONTROL
4 | MANAGEMENT
5 | BREAKPOINT
6 | CONDITION
7 - 63 | <reserved>
Command Classes
Figure 7
Command type codes are assigned in order of expected
frequency of use. Commands and their responses/replies are
numbered sequentially. The command types, ordered by
command class, are:
Page 17
RFC 909 July 1984
Command Class | Command Type | Symbol
----------------+---------------+----------
PROTOCOL | 1 | HELLO
| 2 | HELLO_REPLY
| 3 | SYNCH
| 4 | SYNCH_REPLY
| 5 | ERROR
| 6 | ERRACK
| 7 | ABORT
| 8 | ABORT_DONE
| 9 - 63 | <reserved>
| |
DATA_TRANSFER | 1 | WRITE
| 2 | READ
| 3 | READ_DONE
| 4 | READ_DATA
| 5 | MOVE
| 6 | MOVE_DONE
| 7 | MOVE_DATA
| 8 | REPEAT_DATA
| 9 | BREAKPOINT_DATA
| 10 | WRITE_MASK
| 11 - 63 | <reserved>
| |
CONTROL | 1 | START
| 2 | STOP
| 3 | CONTINUE
| 4 | STEP
| 5 | REPORT
| 6 | STATUS
| 7 | EXCEPTION
| 8 - 63 | <reserved>
| |
MANAGEMENT | 1 | CREATE
| 2 | CREATE_DONE
| 3 | DELETE
| 4 | DELETE_DONE
| 5 | LIST_ADDRESSES
| 6 | ADDRESS_LIST
| 7 | GET_PHYS_ADDRESS
| 8 | GOT_PHYS_ADDRESS
| 9 | GET_OBJECT
| 10 | GOT_OBJECT
| 11 | LIST_BREAKPOINTS
| 12 | BREAKPOINT_LIST
Page 18
LDP Specification Commands and Formats
| 13 | LIST_NAMES
| 14 | NAME_LIST
| 15 | LIST_PROCESSES
| 16 | PROCESS_LIST
| 17 - 63 | <reserved>
| |
BREAKPOINT | 1 | INCREMENT
| 2 | INC_COUNT
| 3 | OR
| 4 | SET_PTR
| 5 | SET_STATE
| 6 - 63 | <reserved>
| |
CONDITION | 1 | CHANGED
| 2 | COMPARE
| 3 | COUNT_EQ
| 4 | COUNT_GT
| 5 | COUNT_LT
| 6 | TEST
| 7 - 63 | <reserved>
Command Types
Figure 8
4.3 Addressing
Addresses are used in LDP commands to refer to memory
locations, processes, buffers, breakpoints and other entities.
Many of these entities are machine-dependent; some machines have
named objects, some machines have multiple address spaces, the
size of address spaces varies, etc. The format for specifying
addresses needs to be general enough to handle all of these
cases. This speaks for a large, hierarchically structured
address format. However, the disadvantage of a large format is
that it imposes extra overhead on communication with targets that
have simpler address schemes.
LDP resolves this conflict by employing two address formats:
a short three-word format for addressing simpler targets, and a
long five-word format for others. Each target LDP is required to
implement at least one of these formats. At the start of an LDP
session, the target specifies the address format(s) it uses in
Page 19
RFC 909 July 1984
the Flag field of the HELLO_REPLY message. In each address, the
first bit of the mode octet is a format flag: 0 indicates LONG
address format, and 1 indicates SHORT format.
4.3.1 Long Address Format
The long address format is five words long and consists of a
three-word address descriptor and a two-word offset (see Figure
9). The descriptor specifies an address space to which the offset
is applied. The descriptor is subdivided into several fields, as
described below. The structuring of the descriptor is designed
to support complex addressing modes. For example, on targets
with multiple processes, descriptors may reference virtual
addresses, registers, and other entities within a particular
process.
The addressing modes defined below are intended as a base to
which target-specific modes may be added. Modes up to 63. are
reserved by the protocol. The range 64. to 127. may be used for
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) | | Descriptor
+---- ID ---+ |
| (15-0) | |
+-------------------------------+ +-+
| (31-16) | |
+---- Offset ---+ | Offset
| (15-0) | |
+-------------------------------+ +-+
Long Address Format
Figure 9
LONG ADDRESS FIELDS:
Page 20
LDP Specification Commands and Formats
Mode
The address mode identifies the type of address space being
referenced. The mode is qualified by the mode argument and
the ID field. Implementation of modes other than physical
and host is machine-dependent. Currently defined modes and
the address space they reference are shown in Figure 10.
Mode | Symbol | Address space
-----+----------------------+---------------------------
0 HOST Host
1 PHYS_MACRO Macromemory
2 PHYS_MICRO Micromemory
3 PHYS_I/O I/O space
4 PHYS_MACRO_PTR Macro contains a pointer
5 PHYS_REG Register
6 PHYS_REG_OFFSET Register plus offset
7 PHYS_REG_INDIRECT Register contains address
of a pointer
8 PROCESS_CODE Process code space
9 PROCESS_DATA Process data space
10 PROCESS_DATA_PTR Process data contains a ptr
11 PROCESS_REG Process virtual register
12 PROCESS_REG_OFFSET Process register plus offset
13 PROCESS_REG_INDIRECT Process register contains
address of a pointer
14 OBJECT_OFFSET Memory object (queue, pool)
15 OBJECT_HEADER System header for an object
16 BREAKPOINT Breakpoint
17 WATCHPOINT Watchpoint
18 BPT_PTR_OFFSET Breakpoint ptr plus offset
19 BPT_PTR_INDIRECT Breakpoint ptr plus offset
gives address of a pointer
20 - <reserved>
63
Long Address Modes
Figure 10
Mode Argument
Page 21
RFC 909 July 1984
Provides a numeric argument to the mode field. Specifies
the register in physical and process REG and REG_OFFSET
modes.
ID Field
Identifies a particular process, buffer or object.
Offset
The offset into the linear address space defined by the
mode. The size of the machine word determines the number of
significant bits in the offset. Likewise, the addressing
units of the target are the units of the offset.
The interpretation of the mode argument, ID field and offset for
each address mode is given below:
HOST
The ID and offset fields are numbers assigned arbitrarily by
the host side of the debugger. These numbers are used in
MOVE and MOVE_DATA messages. MOVE_DATA responses containing
this mode as the destination are sent by the target to the
host. This may occur in debugging when data is sent to the
host from the target breakpoint.
PHYS_MACRO
The offset contains the 32-bit physical address of a
location in macromemory. The mode argument and ID field are
not used. For example, mode=PHYS_MACRO and offset=1000
specifies location 1000 in physical memory.
PHYS_MICRO
Like PHYS_MACRO, but the location is in micromemory.
PHYS_I/O
Like PHYS_MACRO, but the location is in I/O space.
PHYS_MACRO_PTR
The offset contains the address of a pointer in macromemory.
The location pointed to (the effective address) is also in
macromemory. The mode argument and ID field are unused.
Page 22
LDP Specification Commands and Formats
PHYS_REG
The mode argument gives the physical register. If the
register is used by the LDP target process, then the saved
copy from the previous context is used. This comment
applies to PHYS_REG_OFFSET mode as well. The ID field is
not used.
PHYS_REG_OFFSET
The offset is added to the contents of a register given as
the mode argument. The result is used as a physical address
in macromemory. ID is unused.
PHYS_REG_INDIRECT
The register specified in the mode arg contains the address
of a pointer in macromemory. The effective address is the
macromemory location specified in the pointer, plus the
offset. The ID field is unused.
PROCESS_CODE
The ID is a process ID, the offset is into the code space
for this process. Mode argument is not used.
PROCESS_DATA
The ID is a process ID, the offset is into the data space
for this process. Mode argument is not used. On systems
that do not distinguish between code and data space, these
two modes are equivalent, and reference the virtual address
space of the process.
PROCESS_DATA_PTR
The offset contains the address of a pointer in the data
space of the process specified by the ID. The location
pointed to (the effective address) is also in the data
space. The mode argument is not used.
PROCESS_REG
Accesses the registers (and other system data) of the
process given by the ID field. Mode argument 0 starts the
registers. After the registers, the mode argument is an
offset into the system area for the process.
Page 23
RFC 909 July 1984
PROCESS_REG_OFFSET
The offset plus the contents of the register given in the
mode argument specifies a location in the data space of the
process specified by the ID.
PROCESS_REG_INDIRECT
The register specified in the mode arg contains the address
of a pointer in the data space of the process given by the
ID. The effective address is the location in process data
space specified in the pointer, plus the offset.
OBJECT_OFFSET (optional)
The offset is into the memory space defined by the object ID
in ID. Recommended for remote control of parameter
segments.
OBJECT_HEADER (optional)
The offset is into the system header for the object
specified by the ID. Intended for use with the Butterfly.
BREAKPOINT
The descriptor specifies a breakpoint. The offset is never
used, this type is only used in descriptors referring to
breakpoints. (See Breakpoints and Watchpoints, below, for
an explanation of breakpoint descriptors.)
WATCHPOINT
The descriptor specifies a watchpoint. The offset is never
used, this type is only used in descriptors referring to
watchpoints. (See Breakpoints and Watchpoints, below, for
an explanation of watchpoint descriptors).
BPT_PTR_OFFSET
For this mode and BPT_PTR_INDIRECT, the mode argument
specifies one of two breakpoint pointer variables local to
the breakpoint in which this address occurs. These pointers
and the SET_PTR command which manipulates them provide for
an arbitrary amount of address indirection. They are
intended for use in traversing data structures: for example,
chasing queues. In BPT_PTR_OFFSET, the offset is added to
Page 24
LDP Specification Commands and Formats
the pointer variable to give the effective address. In
targets which support multiple processes, the location is in
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 and
watchpoints.
BPT_PTR_INDIRECT
Like BPT_PTR_OFFSET, except that it uses one more level of
indirection. The pointer variable given by the mode
argument plus the offset specify an address which points to
the effective address. See the description of
BPT_PTR_OFFSET for a discussion of usage, limitations and
address space.
4.3.2 Short Address Format
The short address format is intended for use in
implementations where protocol overhead must be minimized. This
format is a subset of the long address format: it contains the
same fields except for the ID field. Therefore, the short
addressing format supports only HOST and PHYS_* address modes.
Only the LOADER_DUMPER implementation level commands may be used
with the short addressing format. The short address format is
three words long, consisting of a 16-bit word describing the
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 ---+ | Offset
| (15-0) | |
+-------------------------------+ +-+
Short Address Format
Figure 11
SHORT ADDRESS FIELDS:
Mode
The high-order bit is 1, indicating the short address
format. A list of the address modes supported is given
below. The interpretation of the remaining fields is as
described above for the long addressing format.
Page 26
LDP Specification Commands and Formats
Mode | Symbol | Address space
-----+--------------------+---------------------------
0 HOST Host
1 PHYS_MACRO Macro-memory
2 PHYS_MICRO Micro-memory
3 PHYS_I/O I/O space
4 PHYS_MACRO_PTR Macro contains a pointer
5 PHYS_REG Register
6 PHYS_REG_OFFSET Register plus offset
7 PHYS_REG_INDIRECT Register contains address
of a pointer
8 -
32 <reserved>
Short Address Modes
Figure 12
Page 27
RFC 909 July 1984
Page 28
LDP Specification Protocol Commands
CHAPTER 5
Protocol Commands
Protocol commands are used for error handling, for
synchronizing the command sequence number, and for communicating
protocol implementation parameters. Every protocol command has a
corresponding reply. All protocol commands are sent from the
host to the target, with replies flowing in the opposite
direction.
5.1 HELLO Command
The HELLO command is sent by the host to signal the start of
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 Format
Figure 13
5.2 HELLO_REPLY
A HELLO_REPLY is sent by the target in response to the HELLO
command at the start of an LDP session. This reply is used to
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 Format
Figure 14
HELLO_REPLY FIELDS:
LDP Version
The target's LDP protocol version. If the current
host protocol version does not agree with the target's
protocol version, the host may terminate the session, or
may continue it, at the discretion of the implementor. The
current version number is 2.
System Type
The type of system running on the target. This is used as a
check against what the host thinks the target is. The host
is expected to have a table of target system types with
information about target address spaces, target-specific
commands and addressing modes, and so forth.
Currently defined system types are shown in Figure 15. This
list includes some systems normally thought of as 'hosts'
(e.g. C70, VAX), for implementations where targets actively
initiate and direct a load of themselves.
Page 30
LDP Specification Protocol Commands
Code | System | Description
--------+---------------+---------------------------
1 C30_16_BIT BBN 16-bit C30
2 C30_20_BIT BBN 20-bit C30
3 H316 Honeywell-316
4 BUTTERFLY BBN Butterfly
5 PDP-11 DEC PDP-11
6 C10 BBN C10
7 C50 BBN C50
8 PLURIBUS BBN Pluribus
9 C70 BBN C70
10 VAX DEC VAX
11 MACINTOSH Apple MacIntosh
System Types
Figure 15
Address Code
The address code indicates which LDP address format(s) the
target is prepared to use. Address codes are show in Figure
16.
Address Code | Symbol | Description
--------------+---------------+-----------------------------
1 LONG_ADDRESS Five word address format.
Supports all address modes
and commands.
2 SHORT_ADDRESS Three word address format.
Supports only physical and
host address modes. Only
the LOADER_DUMPER set of
commands are supported.
Target Address Codes
Figure 16
Implementation
Page 31
RFC 909 July 1984
The implementation level specifies which features of
the protocol are implemented in the target. There are
three levels of protocol implementation. These levels are
intended to correspond to the three most likely applications
of LDP: simple loading and dumping, basic debugging, and
full debugging. (Please see Implementations, above, for a
detailed description of implementation levels.) There are
are also several optional features that are not included in
any particular level.
Implementation levels are cumulative, that is, each higher
level includes the features of all previous levels. The
levels are shown in Figure 17.
Feature Level | Symbol | Description
--------------+---------------+-----------------------------
1 LOADER_DUMPER Loader/dumper subset of LDP
2 BASIC_DEBUGGER Control commands, CREATE
3 FULL_DEBUGGER FSM breakpoints
Feature Levels
Figure 17
Options
The options field (see Figure 18) is an eight-bit flag
field. Bit flags are used to indicate if the target has
implemented particular optional commands. Not all optional
commands are referenced in this field. Commands whose
implementation depends on target machine features are
omitted. The LDP application is expected to 'know' about
target features that are not intrinsic to the protocol.
Examples of target-dependent commands are commands that
refer to named objects (CREATE, LIST_NAMES).
Page 32
LDP Specification Protocol Commands
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
Page 33
RFC 909 July 1984
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.
Page 34
LDP Specification Protocol Commands
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.
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
there are 'holes' in the address space of the object, then
multiple address ranges will be used to describe the valid
address space.
8.7 LIST_BREAKPOINTS Command
The host sends a LIST_BREAKPOINTS command to request a list
of all breakpoints associated with the current connection. The
target replies with BREAKPOINT_LIST.
Page 79
RFC 909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT |LIST_BREAKPOINTS
+---------------+---------------+
LIST_BREAKPOINTS Command Format
Figure 51
8.8 BREAKPOINT_LIST Reply
The target sends a BREAKPOINT_LIST reply to the host in
response to a LIST_BREAKPOINTS command. The reply contains the
sequence number of the LIST_BREAKPOINTS request, and a list of
all breakpoints associated with the current connection. The
descriptor and address of each breakpoint are listed.
Page 80
LDP Specification Management Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | MANAGEMENT |BREAKPOINT_LIST|
+---------------+---------------+
2 | List Sequence Number |
+---------------+---------------+
3 | Flags |M| Item Count |
+---------------+---------------+ +-+
4 | Mode | 0 | |
+---------------+---------------+ |
5 | | | Breakpoint
+-- ID --+ | Descriptor
6 | Field | |
+---------------+---------------+ +-+
7 | Mode | Mode Argument | |
+---------------+---------------+ |
8 | | |
+-- ID --+ | Breakpoint
9 | Field | | Address
+-------------------------------+ |
10| | |
+-- Offset --+ |
11| | |
+-------------------------------+ +-+
* | Additional
* | Descriptor-Address
* | Pairs
+-+
BREAKPOINT_LIST Reply Format
Figure 52
BREAKPOINT_LIST FIELDS:
List Sequence Number
The sequence number of the LIST_BREAKPOINTS command to which
this is the reply.
Flags
Page 81
RFC 909 July 1984
If M=1, the breakpoint list is continued in one or more
subsequent BREAKPOINT_LIST replies. If M=0, this is the
final BREAKPOINT_LIST.
Item Count
The number of breakpoints described in this list.
Breakpoint Descriptor
A descriptor assigned by the target to this breakpoint.
Used by the host to specify this breakpoint in
BREAKPOINT_DATA and DELETE commands.
Breakpoint Address
The address at which this breakpoint is set.
8.9 LIST_PROCESSES Command
The host sends a LIST_PROCESSES command to request a list of
descriptors for all processes on the target. The target replies
with PROCESS_LIST.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT |LIST_PROCESSES |
+---------------+---------------+
LIST_PROCESSES Command Format
Figure 53
Page 82
LDP Specification Management Commands
8.10 PROCESS_LIST Reply
The target sends a PROCESS_LIST reply to the host in
response to a LIST_PROCESSES command. The reply contains the
sequence number of the LIST_PROCESSES request, and a list of all
processes in the target. For each process, a descriptor and a
target-dependent amount of process data are given.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | MANAGEMENT | PROCESS_LIST |
+---------------+---------------+
2 | List Sequence Number |
+---------------+---------------+
3 | Flags |M| Item Count |
+---------------+---------------+ +-+
4 | PROCESS_CODE | 0 | |
+---------------+---------------+ |
5 | | | Process
+-- ID --+ | Descriptor
6 | Field | |
+---------------+---------------+ +-+
7 | Process data count | |
+---------------+---------------+ |
8 | Process data | Process data | |
+-------------------------------+ | Process
* | Data
* |
* |
+---------------+---------------+ |
n | Process data | Process data | |
+-------------------------------+ +-+
* | Additional
* | Descriptor-Data
* | Pairs
+-+
PROCESS_LIST Reply Format
Figure 54
Page 83
RFC 909 July 1984
PROCESS_LIST FIELDS:
List Sequence Number
The sequence number of the LIST_PROCESSES command to which
this is the reply.
Flags
If M=1, the process list is continued in one or more
subsequent PROCESS_LIST replies. If M=0, this is the final
PROCESS_LIST.
Item Count
The number of processes described in this list. For each
process there is a descriptor and a variable number of
octets of process data.
Process Descriptor
A descriptor assigned by the target to this process. Used
by the host to specify this PROCESS in a DELETE command.
Process Data Count
Number of octets of process data for this process. Must be
even.
Process Data
Target-dependent information about this process. Number of
octets is given by the process data count.
8.11 LIST_NAMES Command
The host sends a LIST_NAMES command to request a list of
available names as strings. The target replies with NAME_LIST.
Page 84
LDP Specification Management Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | MANAGEMENT | LIST_NAMES |
+---------------+---------------+
LIST_NAMES Command Format
Figure 55
8.12 NAME_LIST Reply
The target sends a NAME_LIST reply to the host in response
to a LIST_NAMES command. The reply contains the sequence number
of the LIST_NAMES request, and a list of all target names, as
strings.
Page 85
RFC 909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | MANAGEMENT | NAME_LIST |
+---------------+---------------+
2 | List Sequence Number |
+---------------+---------------+
3 | Flags |M| Item Count |
+---------------+---------------+ +-+
4 | Name Size | |
+---------------+---------------+ |
5 | Name Char | Name Char | | Name
+---------------+---------------+ | String
* |
* |
* |
+---------------+---------------+ |
n | 0 or Name Char| 0 | |
+---------------+---------------+ +-+
* | Additional
* | Name
* | Strings
+-+
NAME_LIST Reply Format
Figure 56
NAME_LIST FIELDS:
List Sequence Number
The sequence number of the LIST_NAMES command to which this
is the reply.
Page 86
LDP Specification Management Commands
Flags
If M=1, the name list is continued in one or more subsequent
NAME_LIST replies. If M=0, this is the final NAME_LIST.
Item Count
The number of name strings in this list. Each name string
consists of a character count and a null-terminated string
of characters.
Name Size
The number of octets in this name string. Must be even.
Name Characters
A string of octets composing the name. Ends with a null
octet. The number of characters must be even, so if the
terminating null comes on an odd octet, another null is
appended.
8.13 GET_PHYS_ADDR Command
The host sends a GET_PHYS_ADDR command to convert an address
into physical form. The target returns the physical address in a
GOT_PHYS_ADDR reply. For example, the host could send a
GET_PHYS_ADDR command containing a register-offset address, and
the target would return the physical address derived from this in
a GOT_PHYS_ADDR reply.
Page 87
RFC 909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | MANAGEMENT | GET_PHYS_ADDR |
+---------------+---------------+ +-+
2 | Mode | Mode Argument | |
+---------------+---------------+ |
3 | ID | |
+-- Field --+ |
4 | | | Address
+---------------+---------------+ |
5 | | |
+-- Offset --+ |
6 | | |
+---------------+---------------+ +-+
GET_PHYS_ADDR Command Format
Figure 57
GET_PHYS_ADDR FIELDS:
Address
The address to be converted to a physical address. The mode
may be one of PHYS_REG_OFFSET, PHYS_REG_INDIRECT,
PHYS_MACRO_PTR, any OBJECT_* mode, and any PROCESS_* mode
except for PROCESS_REG.
8.14 GOT_PHYS_ADDR Reply
The target sends a GOT_PHYS_ADDR reply to the host in
response to a successful GET_PHYS_ADDR command. The reply
contains the sequence number of the GET_PHYS_ADDR request, and
the specified address converted into a physical address.
Page 88
LDP Specification Management Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 16 |
+---------------+---------------+
1 | MANAGEMENT | GOT_PHYS_ADDR |
+---------------+---------------+
2 | Get Sequence Number |
+---------------+---------------+ +-+
3 | PHYS_MACRO | 0 | |
+---------------+---------------+ |
4 | | |
+-- 0 --+ |
5 | | | Address
+---------------+---------------+ |
6 | | |
+-- Offset --+ |
7 | | |
+---------------+---------------+ +-+
GOT_PHYS_ADDR Reply Format
Figure 58
GOT_PHYS_ADDR FIELDS:
Get Sequence Number
The sequence number of the GET_PHYS_ADDR command to which
this is the reply.
Address
The address resulting from translating the address given in
the GET_PHYS_ADDR command into a physical address. Mode is
always PHYS_MACRO and ID and mode argument are always zero.
Offset gives the 32-bit physical address.
Page 89
RFC 909 July 1984
8.15 GET_OBJECT Command
The host sends a GET_OBJECT command to convert a name string
into a descriptor. The target returns the descriptor in a
GOT_OBJECT reply. Intended for use in finding control parameter
objects.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | MANAGEMENT | GET_OBJECT |
+---------------+---------------+ +-+
2 | Name Size | |
+---------------+---------------+ |
3 | Name Char | Name Char | | Name
+---------------+---------------+ | String
* |
* |
* |
+---------------+---------------+ |
n | 0 or Name Char| 0 | |
+---------------+---------------+ +-+
GET_OBJECT Command Format
Figure 59
GET_OBJECT FIELDS:
Name String
The name of an object.
Name Size
The number of octets in this name string. Must be even.
Name Characters
A string of octets composing the name. Ends with a null
octet. The number of characters must be even, so if the
Page 90
LDP Specification Management Commands
terminating null comes on an odd octet, another null is
appended.
8.16 GOT_OBJECT Reply
The target sends a GOT_OBJECT reply to the host in response
to a successful GET_OBJECT command. The reply contains the
sequence number of the GET_OBJECT request, and the specified
object name converted into a descriptor.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 12 |
+---------------+---------------+
1 | MANAGEMENT | GOT_OBJECT |
+---------------+---------------+
2 | Get Sequence Number |
+---------------+---------------+ +-+
3 | Mode | Mode Argument | |
+---------------+---------------+ |
4 | | |
+-- ID --+ | Object
5 | | | Descriptor
+---------------+---------------+ +-+
GOT_OBJECT Reply Format
Figure 60
GOT_OBJECT FIELDS:
Get Sequence Number
The sequence number of the GET_OBJECT command to which this
is the reply.
Descriptor
Page 91
RFC 909 July 1984
The descriptor of the object named in the GET_OBJECT
command.
Page 92
LDP Specification Breakpoints and Watchpoints
CHAPTER 9
Breakpoints and Watchpoints
Breakpoints and watchpoints are used in debugging
applications. Each breakpoint or watchpoint is associated with
one debugger connection and one address. When a breakpoint or
watchpoint is triggered, the target executes one or more commands
associated with it. A breakpoint is triggered when its address
is executed. A watchpoint is triggered when its address is
modified. The same mechanism is used for structuring breakpoint
and watchpoint commands. For brevity's sake, 'breakpoint' will
be used in the remainder of this document to refer to either a
breakpoint or a watchpoint.
The commands used by the host to manipulate breakpoints are
given in Figure 61, in the order in which they are normally used.
All commands are sent from the host to the target, and each
specifies the descriptor of a breakpoint.
Command Description
---------------------+------------------------------------
CREATE Create a breakpoint
BREAKPOINT_DATA Send commands to be executed in an
FSM breakpoint
START Activate a breakpoint, set state
and initialize breakpoint variables
STOP Deactivate a breakpoint
CONTINUE Activate a breakpoint
LIST_BREAKPOINTS List all breakpoints
REPORT Report the status of a breakpoint
DELETE Delete a breakpoint
Commands to Manipulate Breakpoints
Figure 61
Page 93
RFC 909 July 1984
There are two kinds of breakpoints: default breakpoints and
finite state machine (FSM) breakpoints. They differ in their use
of commands.
Default breakpoints do not contain any commands. When
triggered, a default breakpoint stops the target object (i.e.,
target process or application) it is located in. A STATUS report
on the stopped object is sent to the host. At this point, the
host may send further commands to debug the target.
An FSM breakpoint has one or more conditional command lists,
organized into a finite state machine. When an FSM breakpoint is
created, the total number of states is specified. The host then
sends commands (using BREAKPOINT_DATA) to be associated with each
state. The target maintains a state variable for the breakpoint,
which determines which command list will be executed if the
breakpoint is triggered. When the breakpoint is created its
state variable is initialized to zero (zero is the first state).
A breakpoint command, SET_STATE, may be used within a breakpoint
to change the value of the state variable. A REPORT command
applied to a breakpoint descriptor returns its address, whether
it is armed or disarmed, and the value of its state variable.
Commands valid in breakpoints include all implemented data
transfer and control commands, a set of conditional commands, and
a set of breakpoint commands. The conditional commands and the
breakpoint commands act on a set of local breakpoint variables.
The breakpoint variables consist of the state variable, a
counter, and two pointer variables. The conditional commands
control the execution of breakpoint command lists based on the
contents of one of the breakpoint variables. The breakpoint
commands are used to set the value of the breakpoint variables:
SET_STATE sets the state variable, SET_PTR sets one of the
pointer variables, and INC_COUNT increments the breakpoint
counter. There may be implementation restrictions on the number
of breakpoints, the number of states, the number of conditions,
and the size of the command lists. Management commands and
protocol commands are forbidden in breakpoints.
In FSM breakpoints, the execution of commands is controlled
as follows. When a breakpoint is triggered, the breakpoint's
state variable selects a particular state. One or more
conditional command lists is associated with this state. A
conditional command list consists of a list of conditions
followed by a list of commands which are executed if the
condition list is satisfied. The debugger starts a breakpoint by
executing the first of these lists. If the condition list is
Page 94
LDP Specification Breakpoints and Watchpoints
satisfied, the debugger executes the associated command list and
leaves the breakpoint. If the condition list fails, the debugger
skips to the next conditional command list. This process
continues until the debugger either encounters a successful
condition list, or exhausts all the conditional command lists for
the state. The relationship of commands, lists and states is
shown in Figure 62 (IFs, THENs and ELSEs are used below to
clarify the logical structure within a state; they are not part
of the protocol).
State 0
IF <condition list 0>
THEN <command list 0>
ELSE IF <condition list 1>
THEN <command list 1>
*
*
*
ELSE IF <condition list n>
THEN <command list n>
ELSE <exit>
*
*
*
State n
Breakpoint Conditional Command Lists
Figure 62
9.1 BREAKPOINT_DATA Command
BREAKPOINT_DATA is a data transfer command used by the host
to send commands to be executed in breakpoints and watchpoints.
The command specifies the descriptor of the breakpoint or
watchpoint, and a stream of commands to be appended to the end of
the breakpoint's command list. BREAKPOINT_DATA is applied
sequentially to successive breakpoint states, and successive
Page 95
RFC 909 July 1984
command lists within each state. Multiple BREAKPOINT_DATAs may
be sent for a given breakpoint. Breaks between BREAKPOINT_DATA
commands may occur anywhere within the data stream, even within
individual commands in the data. Sufficient space to store the
data must have been allocated by the maximum size field in the
CREATE BREAKPOINT/WATCHPOINT command.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | DATA_TRANSFER |BREAKPOINT_DATA|
+---------------+---------------+ +-+
2 | Mode | Mode Argument | |
+---------------+---------------+ | Breakpoint or
3 | | | Watchpoint
+-- ID --+ | Descriptor
4 | Field | |
+-------------------------------+ +-+
5 | Data | Data | |
+-------------------------------+ |
* |
* | Data
* |
+---------------+---------------+ |
n | Data | Data or 0 | |
+---------------+---------------+ +-+
BREAKPOINT_DATA Command Format
Figure 63
BREAKPOINT_DATA FIELDS:
Command Length
Total length of this command in octets, including data,
excluding the final padding octet, if any.
Data
A stream of data to be appended to the data for this
breakpoint or watchpoint. This stream has the form of one
or more states, each containing one or more conditional
Page 96
LDP Specification Breakpoints and Watchpoints
command lists. The first BREAKPOINT_DATA command sent for a
breakpoint contains data starting with state zero. The data
for each state starts with the state size. A conditional
command list is composed of two parts: a condition list, and
a command list. Each list begins with a word that gives its
size in octets.
<state 0 size>
<condition list 0 size> <condition list 0>
<command list 0 size> <command list 0>
*
*
*
<condition list n size> <condition list n>
<command list n size> <command list n>
<state 1 size>
<etc>
*
*
*
<state n size>
Breakpoint Data Stream Format
Figure 64
Page 97
RFC 909 July 1984
Sizes
All sizes are stored in 16-bit words, and include their own
length. The state size gives the total number of octets of
breakpoint data for the state. The condition list size
gives the total octets of breakpoint data for the following
condition list. A condition list size of 2 indicates an
empty condition list: in this case the following command
list is executed unconditionally. The command list size
gives the total octets of breakpoint data for the following
command list.
Lists
Condition and command lists come in pairs. When the
breakpoint occurs, the condition list controls whether the
following command list should be executed. A condition list
consists of one or more commands from the CONDITION command
class. A command list consists one or more LDP commands.
Valid commands are any commands from the BREAKPOINT,
DATA_TRANSFER or CONTROL command classes.
Page 98
LDP Specification Conditional Commands
CHAPTER 10
Conditional Commands
Conditional commands are used in breakpoints to control the
execution of breakpoint commands. One or more conditions in
sequence form a condition list. If a condition list is satisfied
(evaluates to TRUE), the breakpoint command list immediately
following it is executed. (See Breakpoints and Watchpoints,
above, for a discussion of the logic flow in conditional/command
lists.) Conditional commands perform tests on local breakpoint
variables, and other locations. Each condition evaluates to
either TRUE or FALSE. Figure 65 contains a summary of
conditional commands:
Command Description
-----------------------------+------------------------------------
CHANGED <loc> Determine if a location has changed
COMPARE <loc1> <mask> <loc2> Compare two locations, using a mask
COUNT_[EQ | GT | LT] <value> Compare the counter to a value
TEST <loc> <mask> <value> Compare a location to a value
Conditional Command Summary
Figure 65
The rules for forming and evaluating condition lists are:
o consecutive conditions have an implicit logical AND between
them. A sequence of such conditions is called an 'and_list'.
and_lists are delimited by an OR command and by the end of
the condition list.
o the breakpoint OR command may be inserted between any pair of
conditions
o AND takes precedence over OR
o nested condition lists are not supported. A condition list
is simply one or more and_lists, separated by ORs.
Page 99
RFC 909 July 1984
o the condition list is evaluated in sequence until either a
TRUE and_list is found (condition list <- TRUE), or the end
of the condition list is reached (condition list <- FALSE).
An and_list is TRUE if all its conditions are TRUE.
The distillation of these rules into BNF is:
<condition_list> :== <and_list> [OR <and_list>]*
<and_list> :== <condition> [AND <condition>]*
<condition> :== CHANGED | COMPARE | COUNT | TEST
where: OR is a breakpoint command
AND is implicit for any pair of consecutive conditions
For example, the following condition list, with one command per
line,
COUNT_EQ 1
OR
COUNT_GT 10
COUNT_LT 20
evaluates to:
(COUNT = 1) OR (COUNT > 10 AND COUNT < 20)
and will cause the command list that follows it to be executed if
the counter is equal to one, or is between 10 and 20.
10.1 Condition Command Format
Condition commands start with the standard four-octet
command header. The high-order bit of the command type byte is
used as a negate flag: if this bit is set, the boolean value of
the condition is negated. This flag applies to one condition
only, and not to other conditions in the condition list.
Page 100
LDP Specification Conditional Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | Command Length |
+---------------+---------------+
1 | CONDITION |N| Type |
+---------------+---------------+
Condition Command Header
Figure 66
10.2 COUNT Conditions
The COUNT conditions (COUNT_EQ, COUNT_GT and COUNT_LT) are
used to compare the breakpoint counter to a specified value. The
counter is set to zero when the breakpoint is STARTed, and is
incremented by the INC_COUNT breakpoint command. The format is
the same for the COUNT_EQ, COUNT_GT and COUNT_LT conditions.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 8 |
+---------------+---------------+
1 | CONDITION |N| Type |
+---------------+---------------+
2 | |
+-- Value --+
3 | |
+---------------+---------------+
COUNT Condition Format
Figure 67
COUNT_* Condition FIELDS:
Page 101
RFC 909 July 1984
Type
One of COUNT_EQ, COUNT_LT and COUNT_GT. The condition is
TRUE if the breakpoint counter is [EQ | LT | GT] the
specified value.
Value
A 32-bit value to be compared to the counter.
10.3 CHANGED Condition
The CHANGED condition is TRUE if the contents of the
specified location have changed since the last time this
breakpoint occurred. Only one location may be specified as the
object of CHANGED conditions per breakpoint. The CHANGED
condition is always FALSE the first time the breakpoint occurs.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | CONDITION |N| CHANGED |
+---------------+---------------+
2 | |
+-- --+
3 | Address |
+-- --+
4 | |
+-- --+
5 | |
+-- --+
6 | |
+---------------+---------------+
CHANGED Condition
Figure 68
Page 102
LDP Specification Conditional Commands
CHANGED FIELDS:
Address
The full 5-word address of the location to be tested by the
CHANGED command.
10.4 COMPARE Condition
The COMPARE condition compares two locations using a mask.
The condition is TRUE if (<loc1> & <mask>) = (<loc2> & <mask>).
Page 103
RFC 909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 28 |
+---------------+---------------+
1 | CONDITION |N| COMPARE |
+---------------+---------------+
2 | |
+-- --+
3 | Address 1 |
+-- --+
4 | |
+-- --+
5 | |
+-- --+
6 | |
+---------------+---------------+
7 | |
+-- Mask --+
8 | |
+-------------------------------+
9 | |
+-- --+
10| Address 2 |
+-- --+
11| |
+-- --+
12| |
+-- --+
13| |
+-------------------------------+
COMPARE Condition
Figure 69
Page 104
LDP Specification Conditional Commands
COMPARE FIELDS:
Address 1
Address 2
The 5-word addresses of the locations to be compared.
Mask
A 32-bit mask specifying which bits in the locations should
be compared.
10.5 TEST Condition
The TEST condition is used to compare a location to a value,
using a mask. The condition is TRUE if (<loc> & <mask>) =
<value>.
Page 105
RFC 909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 22 |
+---------------+---------------+
1 | CONDITION |N| TEST |
+---------------+---------------+
2 | |
+-- --+
3 | Address |
+-- --+
4 | |
+-- --+
5 | |
+-- --+
6 | |
+---------------+---------------+
7 | |
+-- Mask --+
8 | |
+-------------------------------+
9 | |
+-- Value --+
10| |
+-------------------------------+
TEST Condition
Figure 70
TEST FIELDS:
Address
The 5-word address of the location to be compared to the
value.
Mask
A 32-bit mask specifying which bits in the location should
be compared.
Value
A 32-bit value to compare to the masked location.
Page 106
LDP Specification Conditional Commands
Page 107
RFC 909 July 1984
Page 108
LDP Specification Breakpoint Commands
CHAPTER 11
Breakpoint Commands
Breakpoint commands are used to set the value of breakpoint
variables. These commands are only valid within breakpoints and
watchpoints. They are sent from the host to the target as data
in BREAKPOINT_DATA commands. Figure 71 contains a summary of
breakpoint commands:
Command Description
------------------------+-------------------------------------
INCREMENT <location> Increment the specified location
INC_COUNT Increment the breakpoint counter
OR OR two breakpoint condition lists
SET_PTR <n> <location> Set pointer <n> to the contents of
<location>
SET_STATE <n> Set the breakpoint state variable
to <n>
Breakpoint Command Summary
Figure 71
11.1 INCREMENT Command
The INCREMENT command increments the contents of a specified
location. The location may be in any address space writable from
LDP.
Page 109
RFC 909 July 1984
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 14 |
+---------------+---------------+
1 | BREAKPOINT | INCREMENT |
+---------------+---------------+
2 | |
+-- --+
3 | Address |
+-- --+
4 | |
+-- --+
5 | |
+-- --+
6 | |
+---------------+---------------+
INCREMENT Command Format
Figure 72
INCREMENT FIELDS:
Address
The full address of the location whose contents are to be
incremented.
11.2 INC_COUNT Command
The INC_COUNT command increments the breakpoint counter.
There is one counter variable for each breakpoint. It is
initialized to zero when the breakpoint is created, when it is
armed with the START command, and whenever the breakpoint state
changes. The counter is tested by the COUNT_* conditions.
Page 110
LDP Specification Breakpoint Commands
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | BREAKPOINT | INC_COUNT |
+---------------+---------------+
INC_COUNT Command Format
Figure 73
11.3 OR Command
The OR command delineates two and_lists in a breakpoint
condition list. A condition list is TRUE if any of the OR
separated and_lists in it are TRUE. A breakpoint condition list
may contain zero, one or, many OR commands. See 'Condition
Commands' for an explanation of condition lists.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 4 |
+---------------+---------------+
1 | BREAKPOINT | OR |
+---------------+---------------+
OR Command Format
Figure 74
Page 111
RFC 909 July 1984
11.4 SET_PTR Command
The SET_PTR command loads the specified breakpoint pointer
with the contents of a location. The pointer variables and the
SET_PTR command are intended to provide a primitive but unlimited
indirect addressing capability. Two addressing modes,
BPT_PTR_OFFSET and BPT_PTR_INDIRECT, are used for referencing the
breakpoint pointers. For example, to follow a linked list, use
SET_PTR to load a pointer with the start of the list, then use
successive SET_PTR commands with addressing mode BPT_PTR_OFFSET
to get successive elements.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 16 |
+---------------+---------------+
1 | BREAKPOINT | SET_PTR |
+---------------+---------------+
2 | Pointer |
+---------------+---------------+
3 | |
+-- --+
4 | Address |
+-- --+
5 | |
+-- --+
6 | |
+-- --+
7 | |
+---------------+---------------+
SET_PTR Command Format
Figure 75
SET_PTR FIELDS:
Pointer
The pointer to be changed. Allowable values are 0 and 1.
Address
Page 112
LDP Specification Breakpoint Commands
The full address of the location whose contents are to be
loaded into the given pointer variable.
11.5 SET_STATE Command
The SET_STATE command sets the breakpoint state variable to
the specified value. This is the only method of changing a
breakpoint's state from within a breakpoint. The breakpoint's
state may be also be changed by a START command from the host.
The state variable is initialized to zero when the breakpoint is
created.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 | 6 |
+---------------+---------------+
1 | BREAKPOINT | SET_STATE |
+---------------+---------------+
2 | State Value |
+-------------------------------+
SET_STATE Command Format
Figure 76
SET_STATE FIELDS:
State Value
The new value for the breakpoint state variable. Must not
be greater than the maximum state value specified in the
CREATE BREAKPOINT command that created this breakpoint.
Page 113
RFC 909 July 1984
Page 114
LDP Specification Diagram Conventions
APPENDIX A
Diagram Conventions
Command and message diagrams are used in this document to
illustrate the format of these entities. Words are listed in
order of transmission down the page. The first word is word
zero. Bits within a word run left to right, most significant to
least. However, following a convention observed in other
protocol documents, bits are numbered in order of transmission;
the most significant bit in a word is transmitted first. The bit
labelled '0' is the most significant bit.
0 0 0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+
0 |M| |L|
+---------------+---------------+
1 | Most Sig Octet| Least S. Octet|
+---------------+---------------+
M = most significant bit in word zero,
transmitted first
L = least significant bit in word zero,
transmitted last
Sample Diagram
Figure 77
Page 115
RFC 909 July 1984
Page 116
LDP Specification Command Summary
APPENDIX B
Command Summary
The following table lists all non-breakpoint LDP commands in
alphabetical order, with a brief description of each.
Page 117
RFC 909 July 1984
Sender
Command | Host Target | Function
-------------------+-------------+---------------------------
ABORT X Abort outstanding commands
ABORT_DONE X Acknowledge ABORT
ADDRESS_LIST X Return valid address ranges
BREAKPOINT_DATA X Send breakpoint commands
BREAKPOINT_LIST X Return list of breakpoints
CONTINUE X Resume execution
CREATE X Create target object
CREATE_DONE X Acknowledge CREATE
DELETE X Delete target object
DELETE_DONE X Acknowledge DELETE
EXCEPTION X Report target exception
ERROR X Report error with a host command
ERRACK X Acknowledge ERROR
GET_OBJECT X Get object descriptor from name
GET_PHYS_ADDRESS X Get address in physical form
GOT_OBJECT X Return object descriptor
GOT_PHYS_ADDRESS X Return physical address
HELLO X Initiate LDP session
HELLO_REPLY X Return LDP parameters
LIST_ADDRESSES X Request valid address ranges
LIST_BREAKPOINTS X Request breakpoint list
LIST_NAMES X Request name list
LIST_PROCESSES X Request process list
MOVE X Read data from target
MOVE_DONE X Acknowledge MOVE completion
MOVE_DATA X Send data request by MOVE
NAME_LIST X Return name list
PROCESS_LIST X Return process list
READ X Read data from target
READ_DATA X Return data requested by READ
READ_DONE X Acknowledge READ completion
REPEAT_DATA X Write copies of data
REPORT X Request status of object
START X Start target object
STATUS X Return status of object
STEP X Step execution of target object
STOP X Stop target object
SYNCH X Check sequence number
SYNCH_REPLY X Confirm sequence number
WRITE X Write data
WRITE_MASK X Write data with mask
Page 118
LDP Specification Command Summary
Command Summary
Figure 78
Page 119
RFC 909 July 1984
Page 120
LDP Specification Commands, Responses and Replies
APPENDIX C
Commands, Responses and Replies
The following table shows the relationship between commands,
responses and replies. Commands are sent from the host to the
target. Some commands elicit responses and/or replies from the
target. Responses and replies are sent from the target to the
host. The distinction between them is that the target sends only
one reply to a command, but may send multiple responses.
Responses always contain data, whereas replies may or may not.
Page 121
RFC 909 July 1984
Command | Response | Reply
-------------------+--------------+------------------
ABORT ABORT_DONE
BREAKPOINT_DATA
CONTINUE
CREATE CREATE_DONE
DELETE DELETE_DONE
GET_OBJECT GOT_OBJECT
GET_PHYS_ADDRESS GOT_PHYS_ADDRESS
HELLO HELLO_REPLY
LIST_ADDRESSES ADDRESS_LIST
LIST_BREAKPOINTS BREAKPOINT_LIST
LIST_NAMES NAME_LIST
LIST_PROCESSES PROCESS_LIST
MOVE MOVE_DATA MOVE_DONE
READ READ_DATA READ_DONE
REPEAT_DATA
REPORT STATUS
START
STEP
STOP
SYNCH SYNCH_REPLY
WRITE
WRITE_MASK
Commands, Responses and Replies
Figure 79
Page 122
LDP Specification Glossary
APPENDIX D
Glossary
FSM
Finite state machine. Commands of each breakpoint or
watchpoint are implemented as part of a finite state
machine. A list of breakpoint commands is associated with
each state. There are several breakpoint commands to change
from one state to another.
host
The 'host' in an LDP session is the timesharing system on
which the user process runs.
long
A long is a 32-bit quantity.
octet
An octet is an eight-bit quantity.
RDP
The Reliable Data Protocol (RDP) is a transport layer
protocol designed as a low-overhead alternative to TCP. RDP
is a connection oriented protocol that provides reliable,
sequenced message delivery.
server process
The LDP server process is the passive participant in an LDP
session. The server process usually resides on a target
machine such as a PAD, PSN or gateway. The server process
waits for a user process to initiate a session, and responds
to commands from the user process. In response to user
commands, the server may perform services on the target like
reading and writing memory locations or setting breakpoints.
'Server' is sometimes employed as a shorthand for 'server
process'.
Page 123
RFC 909 July 1984
target
The 'target' in an LDP session is the PSN, PAD or gateway
that is being loaded, dumped or debugged by the host.
Normally, LDP will be implemented in the target as a server
process. However, in some targets with strange
requirements, notably the Butterfly, the target LDP may be a
user process.
user process
The LDP user process is the active participant in an LDP
session. The user process initiates and terminates the
session and sends commands to the server process which
control the session. The user process usually resides on a
timesharing host and is driven by a higher-level entity
(e.g., an application program like an interactive debugger).
'User' is sometimes employed as a shorthand for 'user
process'.
word
A word is a sixteen-bit quantity.
Page 124
INDEX
ABORT command............................................ 35
ABORT_DONE reply......................................... 36
address.............................................. 60, 66
address descriptor....................................... 20
address format................................... 19, 25, 31
address ID............................................... 22
address mode......................................... 20, 22
address mode argument.................................... 21
address offset........................................... 20
addressing............................................... 19
ADDRESS_LIST reply................................... 76, 77
BASIC_DEBUGGER....................................... 12, 32
breakpoint... 9, 13, 57, 60, 71, 79, 92, 93, 95, 96, 99, 107
breakpoint commands.......................... 9, 94, 95, 107
breakpoint counter........................ 94, 100, 101, 110
breakpoint data...................................... 97, 99
breakpoint state variable........................... 94, 107
breakpoint variables..................................... 94
BREAKPOINT_DATA command..................... 73, 94, 95, 107
BREAKPOINT_LIST reply................................ 79, 80
CHANGED condition....................................... 102
command class............................................ 16
command length field..................................... 16
COMPARE Condition....................................... 103
condition command header................................ 101
conditional commands................................. 94, 99
CONTINUE command......................................... 62
control commands...................................... 9, 57
COUNT condition.................................... 110, 111
COUNT_EQ condition...................................... 101
COUNT_GT condition...................................... 101
COUNT_LT condition...................................... 101
CREATE command............................... 69, 70, 73, 75
create types............................................. 70
CREATE_DONE reply.................................... 73, 75
data octets...................................... 43, 47, 52
data packing............................................. 10
data transfer commands................................ 9, 41
data transmission........................................ 10
datagrams................................................. 5
debugging.............................................. 1, 3
Page 125
default breakpoint................................... 71, 92
DELETE command....................................... 73, 75
DELETE_DONE reply........................................ 75
descriptor........... 20, 57, 61, 62, 63, 64, 65, 73, 75, 93
dumping................................................... 3
ERRACK............................................... 10, 39
ERROR codes.............................................. 38
ERROR reply.......................................... 37, 67
EXCEPTION trap........................................... 66
finite state machine................................. 60, 93
FSM breakpoint................................... 71, 92, 94
FULL-DEBUGGER............................................ 12
FULL_DEBUGGER............................................ 32
gateway................................................ 3, 9
GET_OBJECT command................................... 89, 91
GET_PHYS_ADDR command................................ 87, 88
GOT_OBJECT reply..................................... 89, 91
GOT_PHYS_ADDR reply.................................. 87, 88
HELLO command......................................... 9, 29
HELLO_REPLY....................................... 9, 19, 30
host descriptor.......................................... 41
implementation....................................... 12, 31
INC_COUNT command......................... 94, 107, 110, 111
INCREMENT command....................................... 109
internet.................................................. 5
internet protocols........................................ 4
IP........................................................ 5
LDP command formats...................................... 15
LDP header........................................... 15, 16
LDP Version.............................................. 30
LIST commands............................................ 73
LIST_ADDRESSES command............................... 76, 77
LIST_BREAKPOINTS command............................. 79, 80
LIST_NAMES command................................... 84, 85
LIST_PROCESSES command................................... 82
LOADER_DUMPER........................................ 12, 32
loading................................................ 1, 3
long address format...................................... 20
management commands...................................... 67
memory object............................................ 73
MOVE command................................. 22, 41, 47, 49
MOVE sequence number..................................... 52
MOVE_DATA response................................... 22, 51
MOVE_DONE reply.......................................... 52
NAME_LIST reply...................................... 84, 85
offset............................................... 20, 22
OR command.............................................. 111
Page 126
PAD.................................................... 3, 9
pattern.................................................. 54
PHYS_ADDRESS............................................. 57
PHYS_MACRO............................................... 60
PROCESS.................................................. 57
PROCESS_CODE............................................. 60
PROCESS_LIST reply....................................... 82
protocol commands......................................... 9
PSN.................................................... 3, 9
RDP................................................... 5, 15
READ command..................................... 41, 43, 44
READ sequence number..................................... 47
READ_DATA response................................... 45, 46
READ_DONE reply.......................................... 47
repeat count............................................. 54
REPEAT_DATA command.................................. 41, 53
REPORT command................................... 63, 64, 94
sequence number...................................... 10, 39
session................................................... 9
SET_PTR command................................ 94, 111, 112
SET_STATE command.............................. 94, 107, 113
short address format..................................... 25
START command........................................ 59, 60
STATUS reply..................................... 64, 65, 94
STEP command......................................... 62, 63
STOP command......................................... 60, 61
SYNCH.................................................... 10
SYNCH command............................................ 33
SYNCH_REPLY.............................................. 34
system type.............................................. 30
target start address......................... 43, 44, 46, 54
transport................................................. 9
watchpoint.......... 13, 57, 60, 71, 92, 93, 95, 96, 99, 107
WRITE command........................................ 41, 42
WRITE_MASK command....................................... 56
Page 127
Page 128
Loader Debugger Protocol
RFC TOTAL SIZE: 209813 bytes
PUBLICATION DATE: Wednesday, September 23rd, 1992
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|
