RFC 0909
Loader Debugger Protocol
Pages: 135
Experimental
Experimental
Part 1 of 4 – Pages 1 to 34
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
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
A Diagram Conventions................................. 115
B Command Summary..................................... 117
C Commands, Responses and Replies..................... 121
D Glossary............................................ 123
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
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
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.
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.
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
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
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:
+------+
| |
|Appli-|
|cation|
| |
+------+
^
Commands |
V
+------+
| |
| LDP |
| |
+------+
^
Messages |
V
+-----+
| |
| RDP |
| |
+-----+
^
Segments |
V
+----+
| |
| IP |
| |
+----+
^
Datagrams |
V
? * !
$ = ^ +
*
> Internet
, ?
! )
* % $
Form of Data Exchange Between Layers
Figure 2
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
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.
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
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:
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.
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
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
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:
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
| 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
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:
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
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.
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.
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
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.
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.
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
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.
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.
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
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).
(next page on part 2)