HP 3000 Manuals HP 3000 Manuals
DATAB
Debug only
Privileged Mode
Sets a data breakpoint.
Syntax
DATAB virtaddr [:pin|@] [byte_count] [count] [loudness] [cmdlist]
Data breakpoints "break" when the indicated address is written to. The
debugger stops at the instruction that is about to perform the write
operation.
The DATAB command is used to set process-local and global (system-wide)
data breakpoints.
Setting a breakpoint for another process is implemented so that it
appears the target process set the breakpoint itself. Therefore, when
the target process encounters the breakpoint, it enters Debug with its
output directed to the LDEV associated with that process.
Parameters
virtaddr The virtual address at which to set the data breakpoint.
Virtaddr can be a short pointer, a long pointer, or a
full logical code pointer.
pin | @ The process identification number (PIN) of the process
for which the breakpoint is to be set. If omitted, the
breakpoint is set for the current process. The
character "@" can be used to set a global breakpoint at
which all processes stop.
byte_count Byte_count specifies the number of bytes to "protect"
with the data breakpoint. If no value is given, one
byte is assumed.
count Count has a twofold meaning: it specifies to break
every nth time the breakpoint is encountered, and it is
used to set permanent/temporary breakpoints.
If count is positive, the breakpoint is permanent. If
count is negative, the breakpoint is temporary and is
deleted as soon as the process attempts to modify the
protected address. For example, a count of 4 means
break every fourth time the protected address range is
modified; a count of -4 means break on the fourth time,
and immediately delete the breakpoint. If count is
omitted, +1 is used, which breaks every time the address
range is written to, permanently.
loudness Either LOUD or QUIET. If QUIET is selected the debugger
does not print out a message that the breakpoint has
been hit. This is useful for performing a command list
a great number of times before stopping without being
inundated with screen after screen of breakpoint
messages. These keywords may be abbreviated as desired.
The default value is LOUD.
cmdlist A single Debug command or a list of Debug commands that
are executed immediately when the breakpoint is
encountered. Command lists for breakpoints are limited
to 80 characters. (If this is too few characters, write
a macro and have the command list invoke the macro).
Cmdlist has the form:
CMD1
{ CMD1; CMD2; CMD3; ... }
Examples
$ nmdebug > datab dp+c14,8
added: [1] 49.40150c68 for 8 bytes
Set a data breakpoint at DP+c14. (We will assume it's a global
variable.) Protect 8 bytes starting at that address.
$ nmdebug > datab r24,c4,-1
added: T[2] 49.401515d4 for c4 bytes
Set a temporary data breakpoint at the address pointed to by general
register 24. For this example we assume that r24 contains a pointer to
the user's dynamic heap space. Protect c4 bytes starting at that
address. The breakpoint is a temporary breakpoint (that is, it is
deleted after it is encountered for the first time).
$ nmdebug > datab pib(pin)+78:@, 4,, {WL "pib data breakpoint was hit"}
added: @[1] c.c1040480 for 4 bytes
Set a global data breakpoint $78 bytes into the current process's PIB (an
operating system data structure). Protect 4 bytes of data.
$ nmdebug > databl
[1] 49.40150c68 for 8 bytes
T[2] 49.401515d4 for c4 bytes
count 0/1
@[1] c.c1040480 for 4 bytes
cmdlist: {WL "pib data breakpoint was hit"}
Now list the data breakpoints we have just set.
Limitations, Restrictions
Keep in mind that the architecture supports data breakpoints on a page
basis only. Anything more granular requires substantial software
intervention.
CAUTION Data breakpoints on process stacks are not supported, and
setting breakpoints there may crash the system.
Breakpoints set in the global data area of a user's stack are safe as
long as the page containing the global data contains only global data
(that is, the process does not use that page for stacking procedure call
frames or local data).
Setting data breakpoints at addresses on a process stack can severely
degrade performance of the process.
Data breakpoints are ignored in the following circumstances:
* While on the ICS (interrupt control stack).
* While disabled.
* In a "dying" process (See ENV DYING_DEBUG).
* In a job (See ENV JOB_DEBUG).
CAUTION The output format of all System Debug commands is subject to
change without notice. Programs that are developed to
postprocess System Debug output should not depend on the exact
format (spacing, alignment, number of lines, uppercase or
lowercase, or spelling) of any System Debug command output.