Debug Manual

Introduction
Debug Manual—421921-003
1-15
Example of a Memory-Access Breakpoint
system replaces the instruction in the specified location with a breakpoint instruction
and stores the replaced instruction in a breakpoint table. No instructions are moved
except when breakpoints are set and cleared.
Example of a Memory-Access Breakpoint
In addition to code breakpoints, the operating system allows memory-access
breakpoints (one for each process). When you specify a memory-access breakpoint,
you also specify the type of access that triggers the breakpoint. The actual types
available depend on the processor, but possible types are:
•
Read access
•
Write access
•
Read/Write access
•
Change access
When you set a memory-access breakpoint, Debug assigns the address of the
memory-access breakpoint location to a special processor register during execution of
the process that set the breakpoint. If this location is accessed in the specified way, the
processor hardware causes an interrupt that invokes the Debug procedure.
On a memory-access breakpoint, the invocation of Debug is delayed if it occurs within
privileged code and the user is not privileged. For instance, suppose a user process
calls a system library procedure and a memory-access breakpoint occurs during
execution of privileged system code. Because the user is not permitted to debug
privileged code (unless the PRV ON command has been successfully issued),
invocation of Debug is deferred until the process is no longer executing privileged
code. At the point where control is returned to Debug, if the process is still executing in
either the system code or the system library space, Debug cannot modify code in that
space (either directly or indirectly, by setting a breakpoint). Full use of nonprivileged
Debug commands resumes when control is returned to Debug while the process is
executing in the user program.
For other anomalies, see Considerations for Memory-Access Breakpoints on page 2-8.