Exceptions

• Exceptions are a form of ECF, implemented partly by the hardware and partly by the operating system.

• The idea is illustrated in the figure 8.1:

  

  • The processor is executing some current instruction I_curr when a significant change in the processor’s state occurs. The state is encoded in various bits and signals inside the processor. The change in state is known as an event.
  • Example events: a virtual memory page fault occurs, an arithmetic overflow occurs, a system timer goes off, an I/O request completes.
  • In any case, when the processor detects that the event has occurred, it makes an indirect procedure call (the exception), through a jump table called an exception table, to an operating system subroutine (the exception handler) that is specifically designed to process this particular kind of event

Exception handling

• Each type of possible exception in a system is assigned a unique nonnegative integer exception number.

  • Some are assigned by the designers of the processor.
    • Examples: devide by zero, page faults, memory access violations, break-points, arithmetic overflows.
  • Some are assigned by the designers of the operating system kernel:
    • Examples: System calls, Signals from external I/O devices

• At system boot time, the operating system allocates and initializes a jump table called an exception table, so that entry k contains the address of the handler for exception k.

• At run time, the processor detects that an event has occurred and determines the corresponding exception number k. The processor then triggers the exception by making an indirect procedure call, through entry k of the exception table, to the corresponding handler.

  • The exception number is an index into the exception table, whose starting address is contained in a special CPU register called the exception table base register

• Once the hardware triggers the exception, the rest of the work is done in software by the exception handler. After the handler has processed the event, it optionally returns to the interrupted program by executing a special “return from interrupt” instruction, which pops the appropriate state back into the processor’s control and data registers, restores the state to user mode.

• An exception is akin to a procedure call, but with some important differences:

  • Depending on the class of exception, the return address is either the current instruction or the next instruction.
  • The processor also pushes some additional processor state onto the stack that will be necessary to restart the interrupted program when the handler returns. For example, an x86-64 system pushes the EFLAGS register containing the current condition codes, among other things, onto the stack.
  • When control is being transferred from a user program to the kernel, all of these items are pushed onto the kernel’s stack rather than onto the user’s stack.
  • Exception handlers run in kernel mode, which means they have complete access to all system resources.

Summary

Basically, the exception handling is handled by both the hardware and the OS:

• The hardware (processor) triggers the exception (when the events occur).
• The operating system intervenes to handle the exception (exception handlers).

Type of exceptions

Class	Cause	Async/Sync	Return behavior
Interrupt	Signal from I/O device	Async	Always returns to next instruction
Trap	Intentional exception	Sync	Always returns to next instruction
Fault	Potentially recoverable error	Sync	Might return to current instruction
Abort	Nonrecoverable error	Sync	Never returns

• Asynchronous exceptions occur as a result of events in I/O devices that external to the processor.
• Synchronous exceptions occur as a direct result of executing an instruction.

Interrupt

• Hardware interrupts are asynchronous in the sense that they are not caused by the execution of any particular instruction.

• Example: as you type, the keyboard controller issues an electrical signal to the processor to alert the operating system to newly available key presses. These electrical signals are interrupts.The processor receives the interrupt and signals the operating system to enable the operating system to respond to the new data

• Exception handlers for hardware interrupts are often called interrupt handlers.

• Figure 8.5 summarizes the processing for an interrupt:

  • I/O devices trigger interrupts by signaling a pin on the processor chip and placing onto the system bus the exception number.
  • After the current instruction finishes executing, the processor notices that the interrupt pin has gone high, reads the exception number from the system bus, and then calls the appropriate interrupt handler
  • When the handler returns, it returns control to the next instruction.
  • The program continues executing as though the interrupt had never happened.

Traps and System calls

• Traps are intentional exceptions that occur as a result of executing an instruction.
• Traps provides a procedure-like interface between user programs and the kernel, known as a system call. System calls are typically accessed via function calls defined in the C lib.
• User programs often need to request services from the kernel such as reading a file (read), creating a new process (fork), loading a new program (execve), and terminating the current process (exit).
• To allow controlled access to such kernel services, processors provide a special syscall n instruction that user programs can execute when they want to request service n.
• Executing the syscall instruction causes a trap to an exception handler that decodes the argument and calls the appropriate kernel routine.
• A system call runs in kernel mode, which allows it to execute privileged instructions and access a stack defined in the kernel

Fault

• Faults result from error conditions that a handler might be able to correct.
• Figure 8.7 summarizes the processing for a fault:
• Example: the page fault exception, which occurs when an instruction references a virtual address whose corresponding page is not resident in memory and must therefore be retrieved from disk. The page fault handler loads the appropriate page from disk and returns control to the instruction that caused the fault.

Aborts

• Aborts result from unrecoverable fatal errors, typically hardware errors such as parity errors that occur when DRAM or SRAM bits are corrupted
• Figure 8.8 summarizes the processing for an abort:

Exceptions in Linux/x86_64 systems