The preferred way of invoking a system call is determined by the kernel at boot time, and evidently this box uses
sysenter . On an older machine you may see int 0x80 being used instead. In case you
are struggling to make sense of that jump (like I was the first time I saw it) you might be interested to learn
that it's there because
Linus Torvalds is a disgusting pig and proud of it
. (It's a trick to handle restarting of system calls with six parameters).
14 August, 2005
Optimized for Hazardous Nullification
IT's great......I am always wondering that where is this shared librar....
I have search.....Finaly my friend send me this page's link and, problem solved..........
I think this explanation is great.
I'm kind of a newbie when it comes to libraries, but you really explained it very well.
Keep up the good work, and you're more than worth standing on the first page of google. You ought to be on top of the list.
I always thought that AMD was the first to introduce sysenter and sysleave (similar names at least) in K6 CPUs (ages ago) and intel trailed by couple of years. Don't remember whether the opcodes are exactly the same, but the idea is.
The AMD syscall / sysret instructions first appeared in the original K6, which
came after the Pentium Pro. I'm not sure whether the fast system call instructions were part of the acquired
NexGen Nx686 design or if those were added by AMD. Who came up with the idea first? Hard to say. Due to bugs
and limitations neither feature were used in practice until much later.
The opcodes and semantics are different. AMD later adopted Intel's sysenter /
sysexit , and to make things even more confusing Intel now supports syscall /
sysret – in 64-bit mode only.
Thank you very very much. Can you also explain how the the first C compiler was compiled? I mean they wrote it, but how did they compile it?:)
First C compiler was written in assembly. "and compiled with JAVA ;-)" I think you have the answer now.
Thanks Johan for that nice explanation. I could check easily that on my P4 system that was the same. But by the way, how comes that if I compile statically a little C test using the 'open' syscall and disassemble it : I can see that it uses int 0x80 for the trap. Why not always using sysenter ?
Look at this thread: http://lkml.org/lkml/2005/8/11/237
Essentially the int 0x80 is setup up as a system call vector in Linux, and it doesnt have the same effect as issuing a traditional interrupt. This interrupt is handled with a trap gate. It doesnt disable other interrupts or clear any of the IF flags... in other words, I would imagine that calling int 0x80 from glibc (which is where 'open' comes from) is as efficent on modern processor as sysenter, and is done so for compatibility reasons.
Probably a question which should be posted on the glibc mailing list.
Ok - I got curious and researched matth's question some more. I think what is happening is that 0x80 interrupt on 2.6 kernel is setup to jump to the syscall fixed page. in this situation the int 0x80 call is the equivalent of a far jump which goes to this page. there it can use whatever method is setup for syscall implementation.
somebody tell me if i am wrong b/c i'm curious...
You're not wrong Ed, although I think you are getting sidetracked by delving into the kernel-side implementation of int 0x80. It doesn't matter how that's set up by the kernel; syscalls made in this manner will still be slower.
matth sees int 0x80 in his statically linked executables because that's what his static library uses for making syscalls. The static library does not use sysenter directly for its syscall implementation simply because that's not a supported way of making syscalls in Linux. There are only two ways: either you execute int 0x80 or you make a call to __kernel_vsyscall in the shared page I describe above (which in turn uses sysenter if appropriate).
The obvious follow-up question is why the static library code does not call __kernel_vsyscall (since that would be faster). Given suitable start-up code a statically linked executable could indeed figure out whether the fast system call support is available and use it if so, but not all static libraries do this.
Feedback is closed for this entry.
Copyright © 2016 Johan Petersson. All rights reserved.
A proposed update for the "Linus Torvalds is a disgusting pig and proud of it" hyperlink : https://lwn.net/Articles/18419/