Messages in this thread | | | Subject | Re: Need help in understanding x86 syscall | From | Steven Rostedt <> | Date | Thu, 11 Aug 2005 14:17:28 -0400 |
| |
On Thu, 2005-08-11 at 10:59 -0700, Zachary Amsden wrote: > > zach-dev2:~ $ ldd /bin/ls > linux-gate.so.1 => (0xffffe000)
OHHH! So THAT is what linux-gate is used for! Thanks, I've been really confused by that.
> > This is the vsyscall entry point, which gets linked by ld into all > processes. It is a kernel page which is visible to user space, and is > rewritten to support sysenter if indeed that instruction is available. > Glibc has fixed entry points to this page. Here is a view of the system > call entry point on a machine which supports sysenter: > > (gdb) break _init > Breakpoint 1 at 0x8049522 > (gdb) run > Starting program: /bin/ls > (no debugging symbols found)...[Thread debugging using libthread_db enabled] > [New Thread 1075283616 (LWP 5328)] > [Switching to Thread 1075283616 (LWP 5328)] > > Breakpoint 1, 0x08049522 in _init () > (gdb) x/10i 0xffffe400 > 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 >
OK, I get the same on my machine.
> On a machine that does not support sysenter, this will give you: > > int $0x80 > ret > > The int $0x80 system calls are still fully supported by a sysenter > capable kernel, since it must run older binaries and potentially support > syscalls during early boot up before it is known that sysenter is supported.
Now is the latest glibc using this. Since I put in a ud2 op in my sysenter_entry code, which is not triggered, as well as an objdump of libc.so shows a bunch of int 0x80 calls.
-- Steve
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |