Guardian Programmer's Guide

Debugging, Trap Handling, and Signal Handling
Guardian Programmer’s Guide — 421922-014
25 - 14
Disabling Trap Handling
Exiting After an Arithmetic Overflow Trap Condition
If the cause of the trap was an arithmetic overflow condition, then you must reset the
arithmetic overflow bit in the ENV register (bit 10) before exiting the trap handler.
Exiting After a System Code Trap
Another case to be aware of is when exiting the trap handler after a trap condition that
occurred when system code was being executed. Here, when control is passed to the
trap handler, the location of the trap passed to the trap handler is the location of the
call to the system procedure; the S register at the trap contains -1 to signify that a
deferred trap occurred while in system code. Therefore, your process cannot resume
execution at the point of the trap following a trap in system code because the correct
value for the S register is lost. Your program can, however, exit elsewhere. See
Exiting to Another Destination later in this section.
The only trap condition in system code that you can resume after is the process loop-
timer trap. If a process loop-timer times out and causes a trap while in system code,
the trap is deferred until the process returns to the user environment but the value of
the S register at this trap is not -1. In this case, the S register contains the correct
value, which allows the process to easily resume execution following a loop-timer
timeout.
Exiting to Another Destination
A trap handler can exit to some other place in the program, such as a restart point, by
putting the appropriate values into various locations in the region of ‘L’[-5] through
‘L’[8]. The code location is specified in the space index, ENV, and P values. The stack
location is specified in S and L values. Typically, a restart point is at a label at the
beginning of a statement, so the registers are empty: set RP to 7 in ENV.<13:15>
(‘L’[1:8] are immaterial).
Disabling Trap Handling
You can use the ARMTRAP procedure to disable all trap handlers, including Inspect
and Debug, in addition to user-written trap handlers. Doing so causes your process to
abnormally terminate if a trap condition occurs. In the TNS/E environment, the
ARMTRAP procedure disables all trap handlers as the default behavior.
To disable trap handling, set the trap stack address in a call to the ARMTRAP
procedure to a negative number:
CALL ARMTRAP(-1,-1);