x86 处理器清除 IDTR 并在“int $0x80”之后跳转到 EIP 0xe05b答案

【问题标题】：x86 Processor clearing IDTR and jumping to EIP 0xe05b after an 'int $0x80'x86 处理器清除 IDTR 并在“int $0x80”之后跳转到 EIP 0xe05b
【发布时间】：2015-07-07 20:51:02
【问题描述】：

我正在为 x86 处理器创建一个操作系统，并在用户空间中执行一个程序（启用分页）。在程序开始进行系统调用（'int $0x80'）之前，IDTR 指向我的 IDT，0x80 的条目正确地指向我想要执行的函数。在 gdb 中，在一个“si”之后，处理器在地址 0xe05b 处结束，IDTR 完全清除（设置为 0）。

请注意，在进入用户空间之前，'int $0x80' 调用完美运行，它会进入我的函数调用。在执行人工 iret 以到达用户空间后，下一个 'int $0x80' 会导致这种奇怪的行为。

如果有帮助，这一切都是在我更改文件系统代码后开始发生的，但我看不出这与 IDTR 有什么关系。

它似乎也清除了所有其他寄存器，包括堆栈、数据和代码选择器。就像是某种恐慌

有谁知道什么可能导致处理器这样做？

提前致谢！

【问题讨论】：

标签： x86 operating-system kernel interrupt-handling

【解决方案1】：

我遇到了同样的问题，我在执行该过程时通过更改 TSS 中的 ss0 值来纠正它。您的 esp0 值也可能是错误的，但 ss0 应该是 Kernel DS 值 0x18。停止进程时也将 ss0 设置为 0x18。至于esp0，应该是你在execute中留下的esp（我目前只知道）。

【讨论】：

欢迎来到 StackOverflow，在此之前您可能需要阅读 how to post an answer。考虑花时间格式化您的答案，以便读者容易理解。

【解决方案2】：

我将假设您在 bochs 下进行调试。看起来正在发生的事情是您对导致 CPU 重新启动的 CPU 造成了三重故障。 f000:e05b 是调试器在 bochs 启动时在 BIOS 中中断的地址。

可能发生的情况是您的 IDT 在某种程度上是无效的，这会阻止从用户模式传递中断。然后这会导致引发一些其他异常（可能是一般保护错误或双重错误异常）。如果该异常的 IDT 无效，则 CPU 放弃并产生三倍故障，它通过重置自身来处理。

您应该检查您的 IDT 是否可以从用户模式调用。

【讨论】：