为什么使用int80h而不是sysenter来调用系统调用? [英] Why int80h instead of sysenter is used to invoke system calls?
问题描述
所有教科书和Internet资源都告诉我int 80h是一种过时的调用系统调用的样式，在x86平台上已被SYSENTER取代.
All the textbooks and Internet resources tell me int 80h is a stale style for invoking system calls, and has been replaced by SYSENTER on x86 platforms.
但是我只是发现我的系统仍然使用int 80h.我知道像VDSO这样的教科书内容，实现系统调用服务的libc包装器，但是不明白为什么默认情况下仍使用int 80h.
But I just found my system still uses int 80h. I know the textbook stuff like VDSO, libc wrapper that implements the system call service, but don't understand why int 80h is still used by default.
-
有人可以告诉我原因吗?是glibc还是内核太旧了?
Can anybody tell me the reason? The glibc or the kernel is too old?
现在在什么条件下默认仍使用"int 80h"?
Nowadays under what conditions is "int 80h" still used by default?
如何在不安装新glibc的情况下强制执行sysenter?
How can I enforce sysenter without installing a new glibc?
下面是我的环境:
Below is my environment:
我在macbook air 2011(Core Duo CPU)上使用VMWare安装了虚拟机. VM中的32位Ubuntu 8.04/kernel 2.6.24(使用原始.config编译)/libc 2.7.
I installed a virtual machine using VMWare on my macbook air 2011 (Core Duo CPU). 32-bit Ubuntu 8.04/kernel 2.6.24 (compiled using the original .config) /libc 2.7 in the VM.
推荐答案
最有可能出于兼容性原因-32位Ubuntu被编译为与i386处理器兼容(嗯，如今可能还不算老).支持系统(仅出现在Pentium 2 AFAIK上).显然，仅对某些类型的处理器使用针对int 80h的sysenter确实是有益的:
Most likely for compatibility reasons - 32-bits Ubuntu is compiled to be compatible up to the i386 processor (well, maybe not that old nowadays), which did not support sysenter (it only appeared on Pentium 2 AFAIK). Apparently using sysenter against int 80h is really benefical only on some kinds of processors:
http://articles.manugarg.com/systemcallinlinux2_6.html
因此，即使在一般情况下并没有明显的速度提高和更广泛的兼容性，使用sysenter上的int 80h仍然是有意义的，即使在今天也是如此.如果您使用64位版本的Ubuntu，则到处都会使用sysenter/sysexit.
Therefore, if there is no significant speed gain in the general case and broader compatibility, using int 80h over sysenter still makes sense, even today. If you use the 64-bit version of Ubuntu then sysenter/sysexit are used all over the place.
实际上，要使用的系统调用机制是由内核在引导时决定的，而不是由glibc决定的. 此页面(第4.6节)说明了其工作原理很好.在您的情况下，碰巧的是，内核认为VMware模拟的硬件使用int 80h而不是sysenter更为有效.您必须调试内核才能弄清楚它是如何做出决定的.
actually the system call mechanism to use is decided by the kernel at boot time, not by glibc. This page (section 4.6) explains how this works very well. In your case, it just happens that the hardware emulated by VMware is considered by the kernel to be more efficient using int 80h rather than sysenter. You would have to debug the kernel in order to figure out how it makes that decision.
这篇关于为什么使用int80h而不是sysenter来调用系统调用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
