qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]