由用戶態經庫函數進入內核態
為了配合內核使用新的系統調用方式，glibc中要做一定的修改。新的glibc-2.3.2（及其以後版本中）中已經包含了這個改動，在glibc源代碼的sysdeps/unix/sysv/linux/i386/sysdep.h文件中，處理系統調用的宏INTERNAL_SYSCALL在不同的編譯選項下有不同的結果。在打開支持sysenter/sysexit指令的選項I386_USE_SYSENTER下，系統調用會有兩種方式，在靜態鏈接（編譯時加上-static選項）情況下，采用"call *_dl_sysinfo"指令；在動態鏈接情況下，采用"call *%gs:0x10"指令。這兩種情況由glibc庫采用哪種方法鏈接，實際上最終都相當於調用某個固定地址的代碼。下面我們通過一個小小的程序，配合gdb來驗證。
首先是一個靜態編譯的程序，代碼很簡單：
main()
{
getuid();
}將代碼加上static選項用gcc靜態編譯，然後用gdb裝載並反編譯main函數。
[root@test opt]# gcc test.c -o ./static -static [root@test opt]# gdb ./static (gdb) disassemble main 0x08048204 <main+0>: push %ebp 0x08048205 <main+1>: mov %esp,%ebp 0x08048207 <main+3>: sub $0x8,%esp 0x0804820a <main+6>: and $0xfffffff0,%esp 0x0804820d <main+9>: mov $0x0,%eax 0x08048212 <main+14>: sub %eax,%esp 0x08048214 <main+16>: call 0x804cb20 <__getuid> 0x08048219 <main+21>: leave 0x0804821a <main+22>: ret
可以看出，main函數中調用了__getuid函數，接著反編譯__getuid函數。
(gdb) disassemble 0x804cb20 0x0804cb20 <__getuid+0>: push %ebp 0x0804cb21 <__getuid+1>: mov 0x80aa028,%eax 0x0804cb26 <__getuid+6>: mov %esp,%ebp 0x0804cb28 <__getuid+8>: test %eax,%eax 0x0804cb2a <__getuid+10>: jle 0x804cb40 <__getuid+32> 0x0804cb2c <__getuid+12>: mov $0x18,%eax 0x0804cb31 <__getuid+17>: call *0x80aa054 0x0804cb37 <__getuid+23>: pop %ebp 0x0804cb38 <__getuid+24>: ret
上面只是__getuid函數的一部分。可以看到__getuid將eax寄存器賦值為getuid系統調用的功能號0x18然後調用了另一個函數，這個函數的入口在哪裡呢？接著查看位於地址0x80aa054的值。
(gdb) X 0x80aa054
0x80aa054 <_dl_sysinfo>: 0x0804d7f6
看起來不像是指向內核映射頁面內的代碼，但是，可以確認，__dl_sysinfo指針的指向的地址就是0x80aa054。下面，我們試著啟動這個程序，然後停在程序第一條語句，再查看這個地方的值。
(gdb) b main Breakpoint 1 at 0x804820a (gdb) r Starting program: /opt/static Breakpoint 1, 0x0804820a in main () (gdb) X 0x80aa054 0x80aa054 <_dl_sysinfo>: 0xffffe400
可以看到，_dl_sysinfo指針指向的數值已經發生了變化，指向了0xffffe400，如果我們繼續運行程序，__getuid函數將會調用地址0xffffe400處的代碼。
接下來，我們將上面的代碼編譯成動態鏈接的方式，即默認方式，用gdb裝載並反編譯main函數
[root@test opt]# gcc test.c -o ./dynamic [root@test opt]# gdb ./dynamic (gdb) disassemble main 0x08048204 <main+0>: push %ebp 0x08048205 <main+1>: mov %esp,%ebp 0x08048207 <main+3>: sub $0x8,%esp 0x0804820a <main+6>: and $0xfffffff0,%esp 0x0804820d <main+9>: mov $0x0,%eax 0x08048212 <main+14>: sub %eax,%esp 0x08048214 <main+16>: call 0x8048288 0x08048219 <main+21>: leave 0x0804821a <main+22>: ret
由於libc庫是在程序初始化時才被裝載，所以我們先啟動程序，並停在main第一條語句，然後反匯編getuid庫函數。
(gdb) b main Breakpoint 1 at 0x804820a (gdb) r Starting program: /opt/dynamic Breakpoint 1, 0x0804820a in main () (gdb) disassemble getuid Dump of assembler code for function getuid: 0x40219e50 <__getuid+0>: push %ebp 0x40219e51 <__getuid+1>: mov %esp,%ebp 0x40219e53 <__getuid+3>: push %ebx 0x40219e54 <__getuid+4>: call 0x40219e59 <__getuid+9> 0x40219e59 <__getuid+9>: pop %ebx 0x40219e5a <__getuid+10>: add $0x84b0f,%ebx 0x40219e60 <__getuid+16>: mov 0xffffd87c(%ebx),%eax 0x40219e66 <__getuid+22>: test %eax,%eax 0x40219e68 <__getuid+24>: jle 0x40219e80 <__getuid+48> 0x40219e6a <__getuid+26>: mov $0x18,%eax 0x40219e6f <__getuid+31>: call *%gs:0x10 0x40219e76 <__getuid+38>: pop %ebx 0x40219e77 <__getuid+39>: pop %ebp 0x40219e78 <__getuid+40>: ret
可以看出，庫函數getuid將eax寄存器設置為getuid系統調用的調用號0x18，然後調用%gs:0x10所指向的函數。在gdb中，無法查看非DS段的數據內容，所以無法查看%gs:0x10所保存的實際數值，不過我們可以通過編程的辦法，內嵌匯編將%gs:0x10的值賦予某個局部變量來得到這個數值，而這個數值也是0xffffe400，具體代碼這裡就不再贅述。
由此可見，無論是靜態還是動態方式，最終我們都來到了0xffffe400這裡的一段代碼，這裡就是內核為我們映射的系統調用入口代碼。在gdb中，我們可以直接反匯編來查看這裡的代碼
(gdb) disassemble 0xffffe400 0xffffe414 Dump of assembler code from 0xffffe400 to 0xffffe414: 0xffffe400: push %ecx 0xffffe401: push %edx 0xffffe402: push %ebp 0xffffe403: mov %esp,%ebp 0xffffe405: sysenter 0xffffe407: nop 0xffffe408: nop 0xffffe409: nop 0xffffe40a: nop 0xffffe40b: nop 0xffffe40c: nop 0xffffe40d: nop 0xffffe40e: jmp 0xffffe403 0xffffe410: pop %ebp 0xffffe411: pop %edx 0xffffe412: pop %ecx 0xffffe413: ret End of assembler dump.
這段代碼正是arch/i386/kernel/vsyscall-sysenter.S文件中的代碼。其中，在sysenter之前的是入口代碼，在0xffffe410開始的是內核返回處理代碼（後面提到的SYSENTER_RETURN即指向這裡）。在入口代碼中，首先是保存當前的ecx，edx（由於sysexit指令需要使用這兩個寄存器）以及ebp。然後調用sysenter指令，跳轉到內核Ring 0代碼，也就是sysenter_entry入口處。
內核中的處理和返回
sysenter_entry整個的實現可以參見arch/i386/kernel/entry.S。內核處理SYSENTER的代碼和處理INT的代碼不太一樣。通過sysenter指令進入Ring 0之後，由於當前的ESP並非指向正確的內核棧，而是當前CPU的TSS結構中的一個緩沖區（參見上文），所以首先要解決的是修復ESP，幸運的是，TSS結構中ESP0成員本身就保存有Ring 0狀態的ESP值，所以在這裡將TSS結構中ESP0的值賦予ESP寄存器。將ESP恢復成指向正確的堆棧之後，由於SYSENTER不是通過調用門進入Ring 0，所以在堆棧中的上下文和使用INT指令的不一樣，INT指令進入Ring 0後棧中會保存如下的值。
低地址
返回用戶態的EIP
用戶態的CS
用戶態的EFLAGS
用戶態的ESP
用戶態的SS（和DS相同）
高地址
因此，為了簡化和重用代碼，內核會用pushl指令往棧中放入上述各值，值得注意的是，內核在棧中放入的相對應用戶態EIP的值，是一個代碼標簽SYSENTER_RETURN，在vsyscall-sysenter.S可以看到，它就在sysenter指令的後面（在它們之間，有一段NOP，是內核返回出錯時的處理代碼）。接下來，處理系統調用的代碼就和中斷方式的處理代碼一模一樣了，內核保存所有的寄存器，然後系統調用表找到對應系統調用的入口，完成調用。最後，內核從棧中取出前面存入的用戶態的EIP和ESP，存入edx和ecx寄存器，調用SYSEXIT指令返回用戶態。返回用戶態之後，從棧中取出ESP，edx，ecx，最終返回glibc庫。
其它操作系統以及其它硬件平台的支持
值得一提的是，從 Windows XP 開始，Windows 的系統調用方式也從軟中斷 int 0x2e 轉換到采用 sysenter 方式，由於完全不再支持 int 方式，因此 Windows XP 的對 CPU 的最低配置要求是 PentiumII 300MHz。在其它的操作系統例如 *BSD 系列，目前並沒有提供對 sysenter 指令的支持。
在 CPU 方面，AMD 的 CPU 支持一套與之對應的指令 SYSCALL/SYSRET。在純 32 位的 AMD CPU 上，還沒有支持 sysenter 指令，而在 AMD 推出的 AMD64 系列 CPU 上，處於某些模式的情況下，CPU 能夠支持 sysenter/sysexit 指令。在 Linux 內核針對 AMD64 架構的代碼中，采用的還是 SYSCALL/SYSRET 指令。至於這兩種指令最終誰將成為標准，目前還無法得出結論。
未來
我們將 Intel 的 sysenter/sysexit 指令，AMD 的 SYSCALL/SYSRET 指令統稱為"快速系統調用指令"。"快速系統調用指令"比起中斷指令來說，其消耗時間必然會少一些，但是隨著 CPU 設計的發展，將來應該不會再出現類似 Intel Pentium4 這樣懸殊的差距。而"快速系統調用指令"比起中斷方式的系統調用方式，還存在一定局限，例如無法在一個系統調用處理過程中再通過"快速系統調用指令"調用別的系統調用。因此，並不一定每個系統調用都需要通過"快速系統調用指令"來實現。比如，對於復雜的系統調用例如 fork，兩種系統調用方式的時間差和系統調用本身運行消耗的時間來比，可以忽略不計，此處采取"快速系統調用指令"方式沒有什麼必要。而真正應該使用"快速系統調用指令"方式的，是那些本身運行時間很短，對時間精確性要求高的系統調用，例如 getuid、gettimeofday 等等。因此，采取靈活的手段，針對不同的系統調用采取不同的方式，才能得到最優化的性能和實現最完美的功能。
