相关疑难解决方法(0)

陷阱和中断有什么区别？

如果不同系统的术语不同,那么它们在x86上意味着什么？

有人可以解释汇编指令int $0x00和执行实际除法之间的差异.我在与IDT中的第0个条目相关联的内核中的divide_error()处理程序上设置了断点(除法错误).

当我在我的C程序中执行此操作时:

int i = 5/0;

然后我点击了断点(如预期的那样).然而,

asm volatile ("int $0x00")

不会触发处理程序.为什么？

在另一个问题中,有人想知道为什么他们得到一个"浮点错误",实际上他们的C++程序中有一个整数除零.围绕这一点进行了讨论,其中一些断言浮点异常实际上从未因浮点除以零而增加,而只是在整数除以零时出现.

这听起来很奇怪,因为我知道:

1. 所有Windows平台上x86和x64上的MSVC编译代码报告int除以零为"0xc0000094:整数除以零",浮点除以零为0xC000008E"浮点除以零"(启用时)

2. IA-32和AMD64 ISA指定#DE(整数除法异常)作为中断0.浮点异常触发中断16(x87浮点)或中断19(SIMD浮点).

3. 其他硬件具有类似的不同中断(例如, PPC在float-div-by上引发0x7000并且根本不捕获int/0).

4. 我们的应用程序使用_controlfp_s内部(最终stmxcsr操作)取消屏蔽零除零的浮点异常,然后捕获它们以进行调试.所以我在实践中肯定会看到IEEE754被零除的异常.

因此,我得出结论,有些平台将异常作为浮点异常报告,例如x64 Linux(无论ALU管道如何,都会针对所有算术错误提升SIGFPE).

其他操作系统(如果您是操作系统,还是C/C++运行时)报告整数除零作为浮点异常？

我很好奇理解linux中的零除异常处理。当执行零除运算时，将生成陷阱，即将陷阱INT0发送到处理器，并最终将SIGFPE信号发送到执行该操作的进程。

如我所见，除零异常在trap_init()函数中注册为

set_trap_gate(0, &divide_error);

我想详细了解一下，在INT0生成之前和SIGFPE发送到流程之前发生了什么？