RFC 643

Network Debugging Protocol 🎀

Okay bestie, the title block first 💅 This is RFC 643, called Network Debugging Protocol, written by Eric Mader and dated July 1974, with NIC #30873 on it. The title block doesn't say what it obsoletes or updates, and it doesn't list a category or status, so I'm not making any up 🙈

The intro is giving pioneer energy 🧚 This protocol is for a PDP-11 network Bootstrap service and a cross-network debugger. It's built for debugging processes on an operating system that can do the "lower level" debugging stuff, like planting and removing breakpoints and single stepping ✨ If that capability isn't there (a stand-alone program, for example), you can use a subset of it 🦋

It's a level 2 protocol, so it skips the ARPANET HOST-HOST protocol entirely 😭 On TENEX it's done with special privileged system calls that send messages straight to the IMP and receive them straight from it 🔥 Messages go between the PDP-11 and the remote debugger over one link, which is currently 377 octal. Messages from the remote debugger to the PDP-11 are requests asking it to do something. Messages from the PDP-11 back are either a reply to that request, or an indication that a process has stopped running (it trapped, hit a breakpoint, etc.) 💜 The exact message format is shown in Figure 1 below.

Every command has an 8-bit op-code, an 8-bit process-id, two 16-bit arguments, and an optional string of 8-bit bytes 🍓 When the PDP-11 finishes a request successfully, its op-code matches the one the remote host sent. When it fails, it sends that same op-code with the 200 bit set ❌ Op-codes from the PDP-11 with the 100 bit set are asynchronous, meaning a process stopped for a reason other than a request from the remote host (more on those below) ✨ An op-code from the PDP-11 with both the 100 and 200 bits set is meaningless, so don't do that 🙈 Basically, the 8-bit op-code field the PDP-11 sends back works as three things: a CAN'T Flag, an Asynchronous STOP Flag, and a 6-bit op-code 👑

Commands get written out like this, with only the fields that are actually used showing up:

NAME (Process-ID, Argument 1, Argument 2, BYTE STRING)

---

Op-Code 0 - NOP 🌸

This command checks whether the PDP-11 is operational 🫶 It doesn't affect any process running on the PDP-11. The response is:

NOP

Op-Code 1 - DEBUG (Process) 🔍

This command asks for permission to debug the given process 💖 If no other remote host is debugging it right now, the PDP-11 replies with:

DEBUGGING (process)

(op-code 1)

If another remote host has already been given permission to debug that process, or the process doesn't exist, the reply is:

CAN'T DEBUG (process)

(op-code 201) 💀

Op-Code 2 - END DEBUG (Process) 👋

This command gives up the ability to debug a process 🦋 The PDP-11 replies:

END DEBUG (Process)

(op-code 2), unless the remote host isn't debugging that process. In that case it replies:

CAN'T END DEBUG (Process)

(op-code 202) 😭 If the process isn't running when END DEBUG is sent, the effect should be the same as doing:

RESUME (PROCESS)
END DEBUG (PROCESS)

Op-Code 3 - STOP (Process) 🛑

This command asks the PDP-11 to stop the given process from running 💅 The PDP-11 replies:

STOPPED (process)

(op-code 3), unless the process isn't being debugged by the remote host. Then it replies:

CAN'T STOP (process)

(op-code 203) 🙈

Op-Code 4 - DEPOSIT (Process, Address, Count, Byte String) 📥

This tells the PDP-11 to deposit the Count bytes from Byte String into the given process's address space, starting at Address ✨ If it works, the PDP-11 replies:

DEPOSITED (Process, Address, Count)

If the deposit doesn't succeed, or the remote host isn't debugging the process, it replies:

CAN'T DEPOSIT (Process, Address, Count)

Op-Code 5 - RESUME (Process) ▶️

This tells the PDP-11 to let the given process keep running 🚀 The PDP-11 should reply:

RESUMED (Process)

before it actually starts the process, just in case the process traps right away 😭 If the process wasn't stopped, or the remote host isn't debugging it, the reply is:

CAN'T RESUME (Process)

Op-Code 6 - EXAMINE (Process, Address, Count) 🔎

This tells the PDP-11 to send back Count bytes from the given process's address space, starting at Address 🧚 If it can supply the bytes, it replies:

CONTENTS (Process, Address, Count, Byte String)

If all of those bytes don't exist in the address space, or the remote host isn't debugging the process, it replies:

CAN'T EXAMINE (Process, Address, Count)

Op-Code 7 - DEPOSIT STATE VECTOR (Process, Index, Byte Count, Byte String) 🧩

This tells the PDP-11 to deposit the Byte Count bytes from Byte String into the state vector for the given process, starting at byte Index 💜 See Figure 2 for the format of the state vector. The PDP-11 replies:

DEPOSITED STATE VECTOR (Process, Index, Byte Count)

unless the bytes won't all fit in the state vector, or the remote host isn't debugging the process. In that case the reply is:

CAN'T DEPOSIT STATE VECTOR (Process, Index, Byte Count)

Op-Code 10 - BREAK (Process, Address, Proceed Count) 🔴

This tells the PDP-11 to place a breakpoint at Address in the given process's address space, with a proceed count of Proceed Count ✨ You can change the proceed count by sending another BREAK with a different count 🔁 If the breakpoint gets planted, the PDP-11 replies:

BROKE (Process, Address, Proceed Count)

If it can't plant the breakpoint, because the breakpoint tables for the process are full, or because the remote host isn't debugging the process, the reply is:

CAN'T BREAK (Proceed, Address, Proceed Count)

The PDP-11 must keep track of where the breakpoints are, the old contents of those locations, and so on. This is a big deal, so don't skip it 🫶

Op-Code 11 - UNBREAK (Process, Address) 🧹

This tells the PDP-11 to remove the breakpoint at Address in the process's address space, and to release all the storage tied to it 🌈 When the breakpoint is removed, the PDP-11 replies:

UNBROKE (Process, Address)

If the process doesn't have a breakpoint at Address, or the remote host isn't debugging the process, the reply is:

CAN'T UNBREAK (Process, Address)

Op-Code 12 - SINGLE STEP (Process) 👣

This tells the PDP-11 to let the given process execute one instruction, using the Trace Trap feature 🦋 The PDP-11 replies:

SINGLE STEPPING (Process)

before the process is started. If the process is already running, or the remote host isn't debugging it, the reply is:

CAN'T SINGLE STEP (Process)

Op-Code 13 - PROCEED BPT (Process) ⏭️

This tells the PDP-11 to let the process carry on from a breakpoint trap (BPT, see below) 💅 The PDP-11 replies:

PROCEEDING BPT (Process)

before it lets the process proceed. If the process isn't stopped at a breakpoint, or the remote host isn't debugging it, the reply is:

CAN'T PROCEED BPT (Process)

Op-Code 14 - CREATE PROCESS 🌱

This tells the PDP-11 to create a process, with its own virtual address space if the system supports that feature ✨ If it can create the process, the PDP-11 replies with the process-id in process:

CREATED PROCESS (Process)

If the process creation fails, or the system can't create processes, the PDP-11 replies:

CAN'T CREATE PROCESS.

Once a remote host has created a process, it's already debugging that process, so there's no need to send:

DEBUG (process)

Op-Code 15 - DESTROY PROCESS (Process) 💥

This tells the PDP-11 to destroy the given process 🫠 Once the process is destroyed, the remote host obviously can't debug it anymore, so there's no need to send:

END DEBUG (Process).

The PDP-11 replies:

DESTROYED PROCESS (Process)

if the process has been destroyed. If the system doesn't support a multi-process structure, or the remote host isn't debugging the process, the PDP-11 replies:

CAN'T DESTROY PROCESS (Process).

---

Asynchronous Stop Replies ⚡

These replies have op-codes between 100 and 177 octal 🔥 The PDP-11 sends them whenever a process being debugged stops running for any reason other than a response to:

STOP (Process)

Every one of these replies includes the entire state vector for the process 🧠

Op-Code 100 - TRAP (Process, Reason, 0, STATE VECTOR) 🚨

This tells the remote host that a process has "trapped", or terminated abnormally 😱 The Reason is a system error code. In the stand-alone case, it could be a trap vector address instead.

Op-Code 101 - HALT (Process, 0,0, STATE VECTOR) 🏁

This tells the remote host that the given process has terminated normally ✅

Op-Code 102 - BPT (Process, 0, 0, STATE VECTOR) 🔴

This tells the remote host that the given process has hit a breakpoint trap 🎯

Op-Code 103 - TTRAP (Process, 0, 0, STATE VECTOR) 👣

This tells the remote host that the given process has hit a trace trap. In other words, it has just executed one instruction in response to:

SINGLE STEP (Process)

command. 💅 okay so this is where the message format shows up, and it's giving organized 🎀

Every debugger message is laid out like this:

                          Figure 1

             FORMAT OF NETWORK DEBUGGER MESSAGES


                    ----------------
                   | TYPE | HOST    |
                    ----------------
                   | LINK | STYPE   |
                    ----------------
                   | CMD  |  PID    |
                    ----------------
                   |    ARG1        |
                    ----------------
                   |    ARG2        |
                    ----------------

Here's what each field does, bestie 🧚

• TYPE is the HOST-IMP/IMP-HOST message type, and it should always be zero 🙈
• HOST is the source host ID 🌸
• LINK is the debugger link 🔗
• STYPE is the message subtype, and it's always zero 💜
• CMD is the debugger command op-code. Asynchronous replies get the op-code plus an excess of 100, and "can't" replies get it plus an excess of 200. So the reply is literally just the same op-code with a little number on top 💀✨
• PID is the process ID of the process being debugged 🦋
• ARG1 is the first argument of the command 🍓
• ARG2 is the second argument of the command 🫶

Page 8

---

And then the state vectors, which are giving "one big snapshot of the process" energy 📸

                          Figure 2

                  FORMAT OF STATE VECTORS

                      ------------
                     |    R0      |
                      ------------
                     |    R1      |
                      ------------
                     |    R2      |
                      ------------
                     |   ...      |
                      ------------
                     |    PC      |
                      ------------
                     |    PS      |
                      ------------

The vector lists R0, R1, R2 and so on, then PC and PS at the end. Those are the registers and the state that get passed around in those TRAP, HALT, BPT and TTRAP replies. Main character energy, fr fr 👑🌈