From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc909.txt | 7770 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 7770 insertions(+)
 create mode 100644 doc/rfc/rfc909.txt

(limited to 'doc/rfc/rfc909.txt')

diff --git a/doc/rfc/rfc909.txt b/doc/rfc/rfc909.txt
new file mode 100644
index 0000000..b340e79
--- /dev/null
+++ b/doc/rfc/rfc909.txt
@@ -0,0 +1,7770 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                         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
+
-- 
cgit v1.2.3