On 8/14/06, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
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)...
OK, so suppose that glibc does the job for me, how can I get that value of AT_SYSINFO from inside my userspace program? (sorry, I never access to those AT_values before, and don't event know their existence. What are their for, by the way?) Many thanks. H -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
