RFC 0909
Loader Debugger Protocol
Pages: 135
Experimental
Experimental
Part 3 of 4 – Pages 70 to 99
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
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
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.
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.
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
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.
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.
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.
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
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.
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.
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
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
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
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.
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.
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.
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.
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.
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.
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
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
The descriptor of the object named in the GET_OBJECT
command.
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
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
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
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
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
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.
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.
(next page on part 4)