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