The Get Registers request asks the server to send the client the contents of all the debuggee's registers and pseudo registers. It contains no fields other than the message header. Its command code 0xA6.

The fields of the Get Registers response are:

• Message header
• Register list---For an Alpha target this is an array of 65 entries. Each entry is 8 bytes long. The value in each entry is in target machine byte order:
  • Entries 0 to 31 respectively contain the contents of fixed point registers 0 to 31.
  • Entries 32 to 63 respectively contain the contents of floating point registers 0 to 31.
  • Entry 65 contains the debuggee's current program counter.

Possible failure reasons are:

• Bad process ID
• Not connected
• Not stopped

The command code of a Get Registers response is 0x80A6.

C.11.1.17 Set Registers Request and Response

The Set Registers request asks the server to all the debuggee's registers and pseudo registers: including the debuggee's program counter. The request succeeds even if it is unable to change the values of some of the registers. Its fields are:

• Message header
• Register list---For an Alpha target this is an array of 65 entries. Each entry is 8 bytes long. The value in each entry is in target machine byte order:
  • Entries 0 to 31 respectively contain the contents of fixed point registers 0 to 31.
  • Entries 32 to 63 respectively contain the contents of floating point registers 0 to 31.
  • Entry 65 contains the debuggee's current program counter.

The command code of a Set Registers request is 0xA7.

A Set Registers response contains no fields other than the message header. Possible failure reasons are:

• Bad process ID
• Not connected
• Not stopped

The command code of a Set Registers response is 0x80A7.

C.11.1.18 Read Request and Response

A Read request asks the server to read a portion of the debuggee's memory. Its fields are, in order:

• Message header
• Start address---The address of the first byte to read. This is an 8-byte value sent in target machine byte order.
• Number of bytes to read---This is a 4-byte value in sent network order.

Its command code is 0xA8.

The fields of a Read response are, in order:

• Message header
• Start address---The address of the first byte read. This is an 8-byte value sent in target machine byte order.
• Number of bytes read---This is a 4-byte value in sent network order.
• Data read---This is a sequence of bytes. Its length is given by the previous field.

Possible failure reasons are:

• Bad process ID
• Not connected
• Not stopped
• Bad address---The server could not read data from the given address range

The command code of a Read response is 0x80A8.

C.11.1.19 Write Request and Response

A Write request asks the server to overwrite a portion of the debuggee's memory. Its fields are, in order:

• Message header
• Start address---The address of the first byte to read. This is an 8-byte value sent in target machine byte order.
• Number of bytes to write---This is a 4-byte value in sent network order.
• Data to write---This is a sequence of bytes. Its length is given by value of the previous field.

Its command code is 0xA9.

A Write response contains no fields other than the message header. Possible failure reasons are:

• Bad process ID
• Not connected
• Not stopped
• Bad address---The server could not write data to some address in the given address range.

The command code of a Write response is 0x80A9.

C.11.2 Order of Messages

A server can be modeled as a single control thread plus a debuggee thread for each debuggee. Each thread is uniquely identified by its UDP port number. Once a client has sent a message to a thread, it cannot send further messages to that thread (other than copies of the original message) until it receives a response.

A server (control or debuggee) thread can only send responses to the requests it receives. Servers threads are expected to respond promptly to all requests they receive. A server thread must never send more than one response to each message it receives. If it receives a duplicate request it must send a copy of its original response, with an updated retransmission count, without acting a second time on the request.

The only messages a client can send to a control thread are Connect to Process, Connect to Process Insist, and Load Process requests. A positive response to either of these requests identifies a new debuggee thread that the client should use for debugging the new debuggee.

A debuggee thread can be in either running or stopped state. Initially a debuggee thread is in running state. In running state it will accept the following requests:

• Probe Process
• Stop Process
• Disconnect from Process
• Kill Process

The client must not send any other requests to a debuggee thread when it is in running state. A debuggee thread will enter stopped state from running state whenever the debuggee stops. The client can discover the state of a debuggee thread by sending it a probe request. Any debuggee state other than running indicates that the debuggee thread is in stopped state. When it is in stopped state, the client can send the debuggee thread any request except Connect to Process, Connect to Process Insist, or Load Process.

A debuggee thread will return from stopped state to running state when it receives a Continue or Step request that it can act upon.

A debuggee thread will exit immediately after sending a positive Disconnect from Process or Kill Process response. It can also exit at any other time, either through some external cause, or as a result of some other client taking over the debuggee using a Connect to Process Insist request. Once a debuggee thread has exited the server will either ignore requests sent to it or send responses with not connected failure codes.

C.11.3 Recovering from Packet Loss

The standard packet header contains two fields that are used to recover from packet loss:

• The sequence number
• The retransmission count

The sequence number is used to distinguish between different messages. The retransmission count is used to distinguish between copies of the same message. A client should give every message it sends to a particular server thread a different sequence number.

To avoid confusion between different clients started by the same user on the same host, it should also attempt to give load and connect requests sequence numbers that will not be used by other clients. One way to do this would be to base the sequence number upon the time at which the message is sent.

The first time it sends a message it will give it a retransmission count of 0. If it does not receive a response to a request within a reasonable time, it will increment the retransmission count and repeat the message. If after a number of attempts it has still not received a response with the same sequence number and retransmission count as the last message it sent it will assume that the server thread had exited or communications link has failed.

On receiving a duplicate packet, the server should copy the new retransmission count into its original response and send this updated response to the client.

The server cannot normally detect communication failure and will wait indefinitely for messages from a client.

C.12 Transport Layer

The Ladebug Remote Debugger Protocol uses UDP running over an IP network layer as its transport. The client can use any UDP socket as its source but will always send load and connect requests to UDP socket 410. If the request is successful, the response will have as its source socket the socket allocated to the new debuggee thread. The client will send all messages for this debuggee thread to this socket.

The server should always send responses to the source socket of the associated request. The source socket for any message sent by the server should be either 410 (for responses to rejected load and connect messages) or the socket allocated to associated debuggee thread (for all other messages).