HPlogo System Debug Reference Manual > Chapter 4 System Debug Command Specifications

DATAB

MPE documents

Complete PDF
Table of Contents
Index

E0201 Edition 4 ♥
E0300 Edition 3
E0692 Edition 3

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.

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 > databl
       [1] 49.40150c68 for 8 bytes
      T[2] 49.401515d4 for c4 bytes
           count 0/1
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).



D (display)

DATABD