Source files: src/Processor/except.cc, src/Processor/traps.cc, src/Processor/traptable.cc
Header files: incl/Processor/traptable.h, incl/Processor/instance.h, incl/Processor/hash.h
When the processor is first set into exception mode by the graduation functions, it stops decoding new instructions and instead calls the function PreExceptionHandler each cycle. This function makes sure that all stores in the memory unit prior to the excepting instruction have issued to the caches before allowing any exception to trap to the kernel. This step is important if a kernel trap can eventually result in context termination or paging, as the pages needed for the store to take place may no longer be present in the system after such an exception. Soft exceptions (described in Section 3.2.4) may be processed immediately, as these are resolved entirely in hardware.
After the above conditions have completed, PreExceptionHandler calls ExceptionHandler, which starts by flushing the branch queue, the memory unit, the processor stall queue, and the active list, just as in the case of a branch misprediction. Although a real processor would also need to reverse process the register mappings in order to obtain the correct register mapping for continuing execution, the RSIM processor uses its abstraction of logical register files to reload the physical register file and restart with a clean mapping table.
ExceptionHandler then processes exceptions based on the exception type.
ExceptionHandler handles soft-exceptions with the bare minimum amount of processing for an exception. Specifically, the processor PC and NPC are reset, and normal instruction processing occurs as before starting with the instruction in question.
In the case of segmentation faults, the processor must determine whether this is a fault that simply indicates the need for growing the stack or an actual error. If the address is in a region that would be considered appropriate for the processor stack, the function StackTrapHandle is called. This function allocates space for the stack increase and adds those pages to the processor PageTable. For other types of segmentation faults, the function FatalException is called to print information about the type of violation and force all processors in the simulation to a halt.
In the case of an alignment error, this handler first checks to see if the alignment used is actually acceptable according to the ISA (this can arise as double-precision and quadruple-precision floating point loads and stores must only be aligned to single-word boundaries in the SPARC architecture). In such cases, the simulator must seek to emulate the effect of these instructions and then continue. As we expect these occurrences to be rare, RSIM currently does not simulate cache behavior for these accesses, instead calling the corresponding functions in src/Processor/funcs.cc immediately. In cases of genuine alignment failures, the exception is considered nonrecoverable, and FatalException is called.
The function SysTrapHandle handles the emulation of all supported system traps, which include some functions with UNIX-like semantics (close, dup, dup2, exit, lseek, open, read, sbrk, time, times, and write), and some additional traps provided by RSIM (corresponding to the following functions and macros: abort, AssociateAddrNode, endphase, fork, GET_L2CACHELINE_SIZE, getpid, MEMSYS_OFF, MEMSYS_ON, newphase, shmalloc, StatClearAll, StatReportAll, sys_bzero, and sysclocks). The UNIX I/O functions are emulated by actually calling the corresponding functions in the simulator and setting the %o0 register value of the simulated processor to indicate the return value. Note that these accesses are processed by the host filesystem: as a result, simulated programs can actually overwrite system files. The sbrk function is processed by adding pages to the address space for the simulated processor. The time and times functions use the simulated cycle time to set the appropriate return values and structure fields. Although all of these functions have the same behavior as UNIX functions on success (except as noted in Section 5.2) and return the same values on failure, these functions do not set the errno variable on failure. The additional functions provided by RSIM are handled through calls to simulator internal functions, setting the %o0 register value to the result of the trap.
RSIM also uses exceptions to implement certain instructions that either modify system-wide status registers (e.g. LDFSR, STFSR), are outdated instructions with data-paths too complex for a processor with the aggressive features simulated in RSIM (e.g. MULScc), or deal with traps and must have their effects observed in a serial, non-speculative manner (e.g. SAVED and RESTORED, which are invoked just before the end of a window trap to indicate that the processor can modify its CANRESTORE and CANSAVE fields; and DONE and RETRY, which are used to return from a trap back to regular processing [23]). All of these instructions types are marked with SERIALIZE traps, and are handled in ProcessSerializedInstructions. In the case of STFSR and STXFSR, control will be transfered to instructions in the trap-table, while DONE and RETRY transfer control back to the trappc and trapnpc fields saved aside before entering the trap-table. Other serialized instructions continue with normal execution starting from the instruction after the serialized one.
Window traps dispatch control to the trap table through the TrapTableHandle function. This function puts the processor into privileged state and saves aside the PC and NPC of the faulting instruction as trappc and trapnpc. The processor PC and NPC are then set to the appropriate instruction sequences for the window traps, and the processor restarts execution from within those trap-handlers.
For the remaining non-recoverable exceptions (division by zero, floating point error, illegal instruction, priviliged instruction, illegal program counter value), the function FatalException is called.