different levels of ECF:
In general, we refer to these abrupt changes as exceptional control flow (ECF).
Exceptional control flow occurs at all levels of a computer system.
For example, at the hardware level, events detected by the hardware trigger abrupt control transfers to exception handlers.
At the operating systems level, the kernel transfers control from one user process to another via context switches.
At the application level, a process can send a signal to another process that abruptly transfers control to a signal handler in the recipient.
Applications request services from the operating system by using a form of ECF known as a trap or system call.
Software exceptions allow the program to make nonlocal jumps (i.e., jumps that violate the usual call/return stack discipline) in response to error conditions.
Nonlocal jumps are a form of application-level ECF, and are provided in C via the setjmp and longjmp functions.
Understanding these low-level functions will help you understand how higher-level software exceptions can be implemented.
Exceptions
Exceptions are a form of exceptional control flow that are implemented partly by the hardware and partly by the operating system.
An exception is an abrupt change in the control flow in response to some change in the processor’s state.
Figure 8.1 shows the basic idea. In the figure, the processor is executing some current instruction Icurr 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. The event might be directly related to the execution of the current instruction.
For example, a virtual memory page fault occurs, an arithmetic overflow occurs, or an instruction attempts a divide by zero.
On the other hand, the event might be unrelated to the execution of the current instruction. For example, a system timer goes off or 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.
When the exception handler finishes processing, one of three things happens, depending on the type of event that caused the exception:
-
The handler returns control to the current instruction Icurr, the instruction that was executing when the event occurred.
-
The handler returns control to Inext,the instruction that would have executed next had the exception not occurred.
-
The handler aborts the interrupted program.
Exception Handling
Each type of possible exception in a system is assigned a unique nonnegative integer exception number.
Some of these numbers are assigned by the designers of the processor. Other numbers are assigned by the designers of the operating system kernel (the memory-resident part of the operating system).
Examples of the former include divide by zero, page faults, memory access violations, break- points, and arithmetic overflows.
Examples of the latter include system calls and signals from external I/O devices.
At system boot time (when the computer is reset or powered on), the operat- ing system allocates and initializes a jump table called an exception table,
so that entry k contains the address of the handler for exception k.
The exception number is an index into the ex- ception table, whose starting address is contained in a special CPU register called the exception table base register.
An exception is akin to a procedure call, but with some important differences.
（1） As with a procedure call, the processor pushes a return address on the stack before branching to the handler.
However, depending on the class of excep- tion, the return address is either the current instruction or the next instruction
（2）The processor also pushes some additional processor state onto the stack that will be necessary to restart the interrupted program when the handler returns.
（3）If 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.
（4）Exception handlers run in kernel mode (Section 8.2.4), which means they have complete access to all system resources.
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 (Section 8.2.4) if the exception interrupted a user program, and then returns control to the interrupted program.
Classes of Exceptions
Exceptions can be divided into four classes: interrupts, traps, faults, and aborts.
Interrupts
Interrupts occur asynchronously as a result of signals from I/O devices that are external to the processor.
Hardware interrupts are asynchronous in the sense that they are not caused by the execution of any particular instruction.
Exception handlers for hardware interrupts are often called interrupt handlers.
I/O devices such as network adapters, disk controllers, and timer chips trigger interrupts by signaling a pin on the processor chip and
placing onto the system bus the exception number that identifies the device that caused the interrupt.
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 (i.e., the instruction that would have followed the current instruction in the control flow had the interrupt not occurred).
The effect is that the program continues executing as though the interrupt had never happened.
Traps and System Calls
The most important use of traps is to provide a procedure-like interface between user programs and the kernel known as a system call.
To allow controlled access to such kernel services（read, fork, execve, exit, etc）, 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.
From a programmer’s perspective, a system call is identical to a regular function call. However, their implementations are quite different.
Regular functions run in user mode, which restricts the types of instructions they can execute, and they access the same stack as the calling function.
A system call runs in kernel mode, which allows it to execute instructions, and accesses a stack defined in the kernel.