我手头有Linux 内核 3.7.1源代码,因此我将尝试根据这些源代码来回答您的问题。我们在代码中有什么。在arch\x86\kernel\traps.c
我们的函数early_trap_init()
中,可以找到下一个代码行:
set_intr_gate(X86_TRAP_DE, ÷_error);
正如我们所见,set_trap_gate()
被替换为set_intr_gate()
. 如果在下一回合我们扩展这个调用,我们将实现:
_set_gate(X86_TRAP_DE, GATE_INTERRUPT, ÷_error, 0, 0, __KERNEL_CS);
_set_gate
是一个负责两件事的例程:
- IDT 描述符的构造
将构造的描述符安装到 IDT 描述符数组中的目标单元中。第二个只是内存复制,对我们来说并不有趣。但是,如果我们看一下它如何从提供的参数构造描述符,我们将看到:
struct desc_struct{
unsigned int a;
unsigned int b;
};
desc_struct gate;
gate->a = (__KERNEL_CS << 16) | (÷_error & 0xffff);
gate->b = (÷_error & 0xffff0000) | (((0x80 | GATE_INTERRUPT | (0 << 5)) & 0xff) << 8);
或者最后
gate->a = (__KERNEL_CS << 16) | (÷_error & 0xffff);
gate->b = (÷_error & 0xffff0000) | (((0x80 | 0xE | (0 << 5)) & 0xff) << 8);
正如我们在描述符构造的最后看到的那样,我们将在内存中拥有下一个 8 字节的数据结构
[0xXXXXYYYY][0xYYYY8E00], where X denotes digits of kernel code segment selector number, and Y denotes digits of address of the divide_error routine.
这些 8 字节的数据结构是处理器定义的中断描述符。处理器使用它来识别必须采取什么行动来响应接受具有特定向量的中断。现在让我们看看 Intel 为x86处理器家族定义的中断描述符的格式:
80386 INTERRUPT GATE
31 23 15 7 0
+-----------------+-----------------+---+---+---------+-----+-----------+
| OFFSET 31..16 | P |DPL| TYPE |0 0 0|(NOT USED) |4
|-----------------------------------+---+---+---------+-----+-----------|
| SELECTOR | OFFSET 15..0 |0
+-----------------+-----------------+-----------------+-----------------+
在这种格式中,这对SELECTOR:OFFSET定义了函数的地址(以长格式),它将控制以响应中断接受。在我们的例子中__KERNEL_CS:divide_error
,这是divide_error()
除零异常的实际处理程序。
P标志指定描述符应被视为由操作系统正确设置的有效描述符,在我们的例子中它处于提升状态。divide_error()
DPL - 指定可以使用软中断触发功能的安全环。了解该领域的作用需要一些背景知识。
中断源一般分为三种:
- 从操作系统请求服务的外部设备。
- 处理器本身,当发现它进入异常状态时,请求操作系统帮助它摆脱这种状态。
- 在操作系统控制下的处理器上执行的程序,它向操作系统请求一些特殊服务。
最后一种情况以专用指令 int XX 的形式得到处理器的特殊支持。每次程序需要OS服务时,它都会设置描述请求的参数,并发出带有描述中断向量的参数的int指令,供OS提供服务。通过发出 int 指令产生的中断称为软中断。所以在这里,处理器仅在处理软中断时才考虑 DPL 字段,在处理器本身或外部设备产生中断的情况下完全忽略它们。DPL 是一个非常重要的特性,因为它禁止应用程序模拟设备,并由此暗示系统行为。
例如,想象一些应用程序会做这样的事情:
for(;;){
__asm int 0xFF;
//where 0xFF is vector used by system timer, to notify the kernel that the
another one timer tick was occurred
}
在这种情况下,您计算机中的时间会比现实生活中的时间快得多,然后您期望和您的系统期望。因此,您的系统将表现得非常强烈。如您所见,处理器和外部设备被认为是受信任的,但对于用户模式应用程序而言并非如此。在我们的除零异常情况下,Linux 指定该异常只能由环 0 的软中断触发,或者换句话说,只能从内核触发。结果,如果 int 0 指令将在内核空间中执行,处理器将把控制权交给divide_error()
常规。如果在用户空间中执行相同的指令,内核会将其视为保护违规并将控制权传递给通用保护故障异常处理程序(这是所有无效软中断的默认操作)。但是,如果处理器本身尝试将某个值除以零而产生除零异常,则divide error()
无论发生错误除法的空间如何,控制都将切换到例程。一般来说,允许应用程序通过软中断触发除零异常看起来不会有太大的危害。但是对于第一个这将是一个丑陋的设计,对于第二个,一些逻辑可能在幕后,这依赖于一个事实,即除零异常只能由实际不正确的除法运算产生。
TYPE字段指定处理器响应中断接受必须采取的辅助动作。在实践中,仅使用两种类型的异常描述符:中断描述符和陷阱描述符。它们仅在一个方面有所不同。中断描述符强制处理器禁用未来的中断接受,而陷阱描述符则不会。老实说,我不知道为什么 Linux 内核决定将中断描述符用于除零异常处理。陷阱描述符对我来说听起来更合理。
最后一点关于测试程序的混乱输出
Floating point exception (core dumped)
由于历史原因,Linux 内核通过向试图被零除的进程发送SIGFPE(读取 SIGnal Floating Point Exception)信号来回复除零异常。是的,不是SIGDBZ(读取信号除以零)。我知道这已经够混乱了。这种行为的原因是 Linux 模仿了原始UNIX行为(我认为这种行为在 POSIX 中被冻结)和原始UNIX为什么将“除零”异常视为“浮点异常”。我不知道为什么。