On Mon, 2006-08-14 at 13:39 +0900, NAHieu wrote: > On 8/8/06, Manu Garg <manugarg@xxxxxxxxx> wrote: > > On 8/5/06, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote: > > > On Fri, 2006-08-04 at 13:00 -0400, Manu Garg wrote: > > > > I am writing this to announce an article on "sysenter" way of doing > > > > systems calls in newer linux kernels. Here is the link: > > > > http://manugarg.blogspot.com/2006/07/sysenter-based-system-call-mechanism.html > > > > > > > > Abstract: > > > > > > Hi, > > > > > > it's good to see articles like this written. I have one important thing > > > that really should be fixed in it though: You mention several times that > > > the address of the vdso page is 0xffffe400 and you even show an example > > > where userspace calls that address directly. THIS IS WRONG!!! > > > > > > This address is not fixed, and not an ABI and in fact it is changing > > > already in 2.6.18. The actual ABI convention is that the kernel informs > > > userspace of the address via an AT_ elf parameter (AT_SYSINFO to be > > > exact), and applications should use the address they get from this, not > > > the hardcoded value! > > Arjan, this means we must analyze the kernel binary (for AT_SYSINFO) > to get the vsyscall address (which was fixed at 0xffffe400 before) ? Hi, No! The kernel places the AT_SYSINFO value on the stack of the process at start time! (same with the other AT_ values) glibc knows how to parse these values (and you can do it yourself as well, although having glibc do it is better)... Greetings, Arjan van de Ven -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
