Exception and Control Flow

Control Transfer

It is generally refers to the execution of the instructions of the processor. In a high-level overview, we can think of the execution of instruction is sequential. So, each transition from instruction I to instruction I+1 can be thought of control transfer.

Control flow

A sequence of such control transfer can be though as control flow.

The simplest kind of control is when the processor is executing the instruction sequentially (instruction I+1 is executed after instruction I).

Another kind of flow which occurs due to instructions like jump, calls, returns etc which are not sequential in nature.

Third kind of control flow where the transfer of control is not directly due the execution of current program. One instance is data packet arrived at the network port that needs to be stored. To handle this kind of situation processor does an abrupt control transfer and those sequence of flow is known as exception control flow.

Exception

An abrupt change in control flow in response to a state change of the processor.

For example, when some data packets arrive at the network port, then the data needs to be written to the memory.

To handle this kind of event an abrupt change in control flow (a sequence of instruction changes) may happen. This is known as exception.

The exception can happen on various level: hardware level (for example: hardware fault), kernel level (I can understand when kernel does the context switching), User application level (Let's say instruction could not find a file at the file path, an instruction in the application tried to do a division by zero etc.)

When such kind of exception occurs, the operating system does an indirect procedure call (I can think of the scenario as follows) through as jump table

A high-level overview of the process

1. When a system boots up the kernel maintains a jump table (data structure) which maps the exception type (as an unsigned integer number) to the pointer of the respective exception handler.

2. When an exception occurs, we can infer the exception number and then find the particular exception handler from the (base table address+offset) where the offset is the exception number.

3. Then the corresponding exception handler is run (Specific details need to be added, described in the further section).

After finishing the execution of the exception handler either of the three things can happen

1. The handler returns control to the previous executing instruction

2. The handler returns control the instruction which would have been executed next if the exception not occurred.

3. The handler aborts the interrupted program.

Classes of Exception

Interrupts

This is an asynchronous exception happens as a result of signal from the I/o devices that are external to the processor.

Here they are asynchronous in the sense that the exception is not directly caused by the executing instruction.

The handler which handles the interrupts is known as interrupt handler (of course ??)

Traps and system call

This is a synchronous exception happens as a result of current executing instructions.

The important use of traps to provide a procedure like interface between the user programs and the kernel known as system call.

The processor provides a syscall n instruction, that user program can execute when they want to request service n. Executing the syscall instruction causes a trap to an exception handler which decodes the argument and calls the appropriate kernel routine.

But this may feel like a simple function call. but in reality, there is some distinction. This system call runs on kernel mode (Exploring further on low level details of the kernel mode).

Aborts

Aborts result from unrecoverable fatal error, typically due to hardware failures. In this case the exception handler never return control to the application program.

For example, the exception number 18 (machine check) defined in x86-64 systems falls under aborts.

This exception occurs when a problem related to the hardware is detected. In most case when BSOD (Blue screen of death occurs) in a windows system that is the result of this exception.

Faults

Faults result from error conditions that a handler might be able to correct. When this exception occurs the processor transfers control to the handler, If the handler is able to correct it then returns the control to the faulty executing instruction to re-execute the instruction.

If it is not able to correct the error the handler returns to an abort routine in the kernel that terminates the program causing the fault.

Some exceptions of linux/x86-64 systems

Divide error Fault: A divide error (Exception 0) occurs when application attempts to divide by zero, or the result is very big to fit in the destination operand

General protection fault: Famous segmentation fault (exception number 13), when a program attempts to write to a read-only (text segment where instruction is stored) or references to an undefined area of the virtual memory.

Machine check Abort: when a fatal hardware error that is detected when executing a faulting instruction. This exception handler never return control to the application program.