Static and Nonstatic Watchpoints

    The technique for setting a watchpoint depends on whether the
    variable is static or nonstatic.

    A static variable is associated with the same memory address
    throughout execution of the program. You can always set a
    watchpoint on a static variable throughout execution.

    A nonstatic variable is allocated on the call stack or in a
    register and has a value only when its defining routine is active
    (on the call stack). Therefore, you can set a watchpoint on a
    nonstatic variable only when execution is currently suspended
    within the scope of the defining routine (including any routine
    called by the defining routine). The watchpoint is canceled when
    execution returns from the defining routine. With a nonstatic
    variable, the debugger traces every instruction to detect any
    changes in the value of a watched variable or location.

    Another distinction between static and nonstatic watchpoints
    is speed of execution. To watch a static variable, the debugger
    write-protects the page containing the variable. If your program
    attempts to write to that page, an access violation occurs and
    the debugger handles the exception, determining whether the
    watched variable was modified. Except when writing to that page,
    the program executes at normal speed.

    To watch a nonstatic variable, the debugger traces every
    instruction in the variable's defining routine and checks the
    value of the variable after each instruction has been executed.
    Since this significantly slows execution, the debugger issues a
    message when you set a nonstatic watchpoint.

    As explained in the next paragraphs, /[NO]STATIC, /INTO, and
    /OVER enable you to exercise some control over speed of execution
    and other factors when watching variables.

    The debugger determines whether a variable is static or nonstatic
    by checking how it is allocated. Typically, a static variable is
    in P0 space (0 to 3FFFFFFF, hexadecimal); a nonstatic variable is
    in P1 space (40000000 to 7FFFFFFF) or in a register. The debugger
    issues a warning if you try to set a watchpoint on a variable
    that is allocated in P1 space or in a register when execution is
    not currently suspended within the scope of the defining routine.

    The /[NO]STATIC qualifiers enable you to override this default
    behavior. For example, if you have allocated nonstack storage
    in P1 space, use /STATIC when setting a watchpoint on a variable
    that is allocated in that storage area. This enables the debugger
    to use the faster write-protection method of watching the
    location instead of tracing every instruction. Conversely, if,
    for example, you have allocated your own call stack in P0 space,
    use /NOSTATIC when setting a watchpoint on a variable that is
    allocated on that call stack. This enables the debugger to treat
    the watchpoint as a nonstatic watchpoint.

    You can also control the execution speed for nonstatic
    watchpoints in called routines by using /INTO and /OVER.

    On Alpha processors, both static and nonstatic watchpoints are
    available. With static watchpoints, the debugger write-protects
    the page of memory in which the watched variable is stored.
    Static watchpoints, therefore, would interfere with the system
    service itself if not for the debugger's use of system service
    interception (SSI).

    If a static watchpoint is in effect then, through system service
    interception, the debugger deactivates the static watchpoint,
    asynchronous traps (ASTs), and thread switching, just before the
    system service call. The debugger reactivates them just after
    the system service call completes, putting the watchpoint, AST
    enabling, and thread switching back to their original state
    and, finally, checking for any watchpoint hits. This behavior
    is designed to allow the system service to run as it normally
    would (that is, without write-protected pages) and to prevent
    the AST code or a different thread from potentially changing the
    watchpointed location while the watchpoint is deactivated. Be
    aware of this behavior if, for example, your application tests to
    see if ASTs are enabled.

    An active static watchpoint can cause a system service to fail,
    likely with an ACCVIO status, if the system service is not
    supported by the system service interception (SSI) vehicle (
    SYS$SSISHR on OpenVMS Alpha systems). Any system service that is
    not in SYS$PUBLIC_VECTORS is unsupported by SSI, including User
    Written System Services (UWSS) and any loadable system services,
    such as $MOUNT.

    When a static watchpoint is active, the debugger write-protects
    the page containing the variable to be watched. A system service
    call not supported by SSI can fail if it tries to write to that
    page of user memory.

    To avoid this failure, do either of the following:

    o  Deactivate the static watchpoint before the service call.
       When the call completes, check the watchpoint manually and
       reactivate it.

    o  Use nonstatic watchpoints. Note that nonstatic watchpoints can
       slow execution.

    If a watched location changes during a system service routine,
    you will be notified, as usual, that the watchpoint occurred.
    Note that, on rare occasions, stack may show one or more debugger
    frames on top of the frame or frames for your program. To work
    around this problem, enter one or more STEP/RETURN commands to
    get back to your program.

    System service interception is on by default, but on Alpha
    processors only, you can disable interception prior to a
    debugging session by issuing the following command:

    $  DEFINE SSI$AUTO_ACTIVATE OFF

    To reenable system service interception, issue one of the
    following commands:

    $  DEFINE SSI$AUTO_ACTIVATE ON
    $  DEASSIGN SSI$AUTO_ACTIVATE