Software-Generated Exceptions
General
Software-generated exceptions fall into two categories:
Software exceptions generated as a result of an error condition detected while attempting execution of an instruction. The type of error condition defines the IDT entry that is vectored to.
Software exceptions deliberately generated by execution of special instruction types (e.g., INT and BOUND). Special exceptions are also generated by the INT nn, INTO, and INT3 instructions:
- Execution of an INT nn instruction vectors to entry nn in the IDT.
- Execution of an INTO instruction vectors to IDT entry four if EFlags[OF] = 1.
- Execution of the INT3 instruction (the breakpoint instruction) vectors to IDT entry three.
- Conditionally generated by the BOUND instruction if the indicated array index is not within the bounds of the indicated memory array (this causes the processor to vector to IDT entry five).
Faults, Traps, and Aborts
Due to a problem with the instruction itself or with an operand it attempts to access, the attempted execution of an instruction may result in the detection of an error condition. Problems of this nature are referred to as software exception conditions. When such a problem is detected, the processor invokes a special exception handler routine designed to attempt a graceful recovery from the respective exception condition.
The pointers to the various exception handlers are stored in dedicated entries in the IDT. Software exceptions are categorized as faults, traps, or aborts. These terms are defined in Table 14-2 on page 260. Table 14-3 on page 261 defines each software exception and identifies it as a fault, trap, or abort.
| Vector | Description | Type |
|---|---|---|
| 0 | A Divide-By-Zero exception can be generated during execution of the DIV or IDIV instruction. A detailed description of this exception can be found in “Divide-by-Zero Exception (0)” on page 291. | fault |
| 1 | A debug exception caused by the detection of an instruction address breakpoint. A detailed description of this exception can be found in “Debug Exception (1)” on page 292. | fault |
| A debug exception caused by the detection of a data address breakpoint. | trap | |
| A Debug exception caused by a General Detect condition. This occurs when an attempt is made to use the processor's debug registers when they are already in use by an in-circuit emulator (ICE). | fault | |
| A Debug exception caused by the single-step interrupt. | trap | |
| A Debug exception caused by a task-switch breakpoint. | trap | |
| 2 | NMI is not a software exception. | trap |
| 3 | The INT3 instruction is also referred to as the Breakpoint instruction. Unlike the two-byte INT nn instruction, it is one byte long. A detailed description of this exception can be found in “Breakpoint Exception (3)” on page 294. | trap |
| 4 | Generated by the execution of the INTO instruction if EFlags[OF] = 1. Useful because the signed and unsigned arithmetic instructions cannot detect an overflow of the result. A detailed description of this exception can be found in “Overflow Exception (4)” on page 295. | trap |
| 5 | Generated by the BOUND instruction if the specified array index is not within the bounds of the specified memory array. A detailed description of this exception can be found in “Array Bounds Check Exception (5)” on page 296. | fault |
| 6 | Generated when an invalid opcode is detected upon the attempted execution of the instruction (instruction prefetch cannot cause this exception). Also generated when an invalid operand is used with an instruction (e.g., specifying a register as the target of a jump). Use of the LOCK prefix with instructions for which locking is not supported also causes this exception. A detailed description of this exception can be found in “Invalid OpCode Exception (6)” on page 297. | fault |
| 7 | The Device Not Available (DNA) exception is generated under two circumstances:
| fault |
| 8 | Double-fault encountered. The processor has encountered a fault while attempting to call an exception handler for a previously-encountered fault. Most of the time this can be handled by servicing the two exceptions serially, but some combinations are unrecoverable. Such combinations result in a double-fault exception. If a third exception occurs while the processor is attempting to call the double-fault handler, the processor generates the Special transaction to broadcast a Shutdown message and then enters the Shutdown state. A detailed description of this exception can be found in “Double Fault Exception (8)” on page 300. | abort |
| 9 | The Coprocessor segment overrun abort is reserved in the post-386 processors. It was only generated by the 386 when a page or segment violation was detected during the transfer of an operand to or from memory. The later processors generate exception 13h instead (General Protection). A detailed description of this exception can be found in “Coprocessor Segment Overrun Exception (9)” on page 303. | abort |
| 10[*] | Invalid TSS fault. Generated if a task switch is attempted to a task with an invalid TSS. A detailed description of this exception can be found in “Invalid TSS Exception (10)” on page 304. | fault |
| 11[*] | Segment Not Present. Generated when the selected segment descriptor (CS, DS, ES, FS, GS) has its P bit = 0. An SS descriptor with P = 0 results in a stack exception (number 12). A detailed description of this exception can be found in “Segment Not Present Exception (11)” on page 307. | fault |
| 12 | Stack exception occurs for one of two reasons:
| fault |
| 13 | General Protection (GP) exception. All protection violations that don't cause another exception cause a GP exception. A detailed description of this exception can be found in “General Protection (GP) Exception (13)” on page 310. | fault or trap |
| 14[*] | Page Fault exception. Occurs for one the following reasons:
| fault |
| 15 | Reserved. | n/a |
| 16 | FP error exception. Error generated by the attempted execution of a FP math instruction. It can only occur when CR0[NE] = 1. A detailed description of this exception can be found in “FPU Exception (16)” on page 317. | fault |
| 17-31 | Intel® reserved. Do not use. Note that some of these were subsequently implemented in later IA32 processors. | n/a |
| 32-255 | Available for use by maskable hardware interrupts and the INT nn instruction. | traps |
[*] Note: These exceptions do not occur in Real Mode but may occur in VM86 mode.
Instruction Restart
When the processor generates any of the fault exceptions, it restores all of its registers to the state that they were in prior to the attempted execution of the instruction. The return address pushed onto the stack by the exception is therefore the CS:EIP value that points to the instruction that caused the fault. This permits the fault handler to examine the instruction in question and determine whether or not it can correct the problem and then re-execute the instruction successfully.
A classic example would be a Page Fault exception. This occurs because the target page of information is not currently present in memory. In the exception handler, the programmer could take the following actions:
Read the page from mass storage into a physical page in memory.
Create a Page Table Entry (PTE) mapping any address within the linear page to that physical page.
Resume execution of the interrupted program at the instruction that caused the Page Fault exception.
When the instruction is re-executed, the access takes place successfully because the target page is now present in memory, resulting in a successful Page Table lookup and therefore a successful address translation.
Software Interrupt Instructions
The software interrupt instruction (INT nn) emulates the hardware interrupt mechanism. Consider the following example instruction (assume that the system is a PC running DOS):
INT 13h ;call disk bios routine
When this instruction is executed by the processor, the following events take place:
The processor uses the immediate operand, 13h, as an index into the IDT.
The processor reads the contents of IDT entry 13h (19d) from memory.
The processor pushes the contents of its CS, EIP and EFlags registers onto the stack. This is necessary to save its place in the interrupted program, as well as saving the state of the interrupt enable bit (EFlags[IF]).
The processor sets EFlags[IF] = 0 to disable recognition of external hardware interrupts.
The processor jumps to the device-specific interrupt service routine pointed to by the IDT entry.
At the end of the routine, an interrupt return (IRET) instruction is executed, causing the processor to pop the original CS, EIP and EFlags values from the stack and into their respective registers.
The processor resumes execution of the interrupted program.