操作系统中断处理程序应如何处理与编码错误相关的中断?
例如,我试图除以0来测试我的中断,但我的中断处理程序被调用了。但是,由于div指令没有成功执行,EIP不会更新到它之后的下一条指令,并且在使用iret
从中断处理程序返回后,它会再次返回到错误的div
指令。
mov ax, 3
mov dl, 0
div dl ; go back here again and again
处理此中断的正确方式是什么?我想到了几种方式:
将dl
更改为0以外的值。但是,我不确定dl
是否能在发生情况时保持,中断例程应该是在退出后恢复寄存器,我不认为通过提供错误的计算来默默纠正错误是好的。
检索div
之后的下一条指令。然而,我还没有想出任何简单可靠的方法来获得下一条指令。
将当前包含返回地址的堆栈顶部修改为其他代码的地址。因此,我们不再返回到div
说明。
您说得对,在此特定中断的情况下,这些都不是特别好的事情。正如注释中所提到的,因为您有指令的地址,所以您可以获取该地址处的任何内容,对指令进行解码,然后将指针前进到下一个地址。但代码不会预料到这一点!
在POSIX操作系统中,SIGFPE信号掩盖了这种异常行为。如果您正在编写操作系统并希望遵循POSIX,那么您的中断处理程序应该将该信号发送给进程。如果进程具有该信号的处理程序,则跳转到该处理程序并允许该进程处理该信号(例如,这就是高级语言中的Try/Catch块的工作方式……现在您知道为什么异常很慢了吧!)如果没有信号处理程序,则应该终止该进程(并重新进入您的调度程序以确定下一步要做什么……希望是PID1!)。
当然,这是您的操作系统,如果您不想遵循POSIX,则没有理由必须遵循POSIX!如果您有其他奇妙的方法来处理User程序中的错误,那么您可以实现它。上一篇:隐藏或取消隐藏所有Excel工作表,而不循环而不、工作、Excel
下一篇:DotNetOpenAuth:如何实现一个简单的OpenID提供商?如何实现、提供商、简单、DotNetOpenAuth