On Sun, Oct 18, 2009 at 4:47 AM, Jamie Lokier <ja...@shareable.org> wrote: > Laurent Desnogues wrote: >> A recent compiler (gcc 4.4.0) produces this code for a statically >> compiled program: >> >> 00000000005779e0 <time>: >> 5779e0: 48 83 ec 08 sub $0x8,%rsp >> 5779e4: 48 c7 c0 00 04 60 ff mov $0xffffffffff600400,%rax >> 5779eb: ff d0 callq *%rax >> 5779ed: 48 83 c4 08 add $0x8,%rsp >> 5779f1: c3 retq > > Yes. It's a fixed address. See the kernel at > linux/arch/x86/kernel/vsyscall_64.c. There are only 3 vsyscall > functions defined: vgettimeofday, vtime and vgetcpu.
My proposed patch already implements vgettimeofday and vtime. vgetcpu is TBD. > Even though it's a statically linked program, I'm not sure if the > above code will work on really old kernels. All I can say is that it's what my toolchain generates. Interestingly, dynamically shared programs don't run with QEMU on my machine. It looks like the PC is completely wrong. > The vsyscall page is different from the vdso, which has variable > address, and the address is supplied to Glibc. vdso provides nearly > the same functions in a different way. I don't understand how vdso and vsyscall interact (or don't interact): as I showed above, a statically linked program will use vsyscall. For dynamically linked program, I can't say, given what I said above; there might be a loader issue here. Laurent
