[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall
From: |
Laurent Desnogues |
Subject: |
Re: [Qemu-devel] [PATCH] User mode: Handle x86_64 vsyscall |
Date: |
Sun, 18 Oct 2009 13:23:30 +0200 |
On Sun, Oct 18, 2009 at 4:47 AM, Jamie Lokier <address@hidden> 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