Hello,
I'm a bit puzzled because vdso doesn't seem to be used on my fedora 7:
I just compiled a trivial program which just call gettimeofday() and
ld.so resolves this call with vsyscall's gettimeofday.
Now I'm wondering when vdso is used, could anybody give me a clue ?
Another question: is vdso going to replace vsyscall at all ? If so how
are statically programs going to be handled ?
Thanks,
--
Francis
On 9/16/07, Francis Moreau <[email protected]> wrote:
> I'm a bit puzzled because vdso doesn't seem to be used on my fedora 7:
> I just compiled a trivial program which just call gettimeofday() and
> ld.so resolves this call with vsyscall's gettimeofday.
>
> Now I'm wondering when vdso is used, could anybody give me a clue ?
F7 was released before the vdso for x86_64 was upstream so you should
not expect anything else. F8 will use the available vdso. This
doesn't just happen magically, changes to libc are needed.
> Another question: is vdso going to replace vsyscall at all ? If so how
> are statically programs going to be handled ?
Unfortunately the vsyscalls cannot ever go completely away.
Statically linked apps, the bane of progress, will need them. There
are also people updating kernels but not the user userland code.
What we will have to do in future is to make vsyscalls configurable.
Both a compile time option and a runtime option (perhaps also under
control of SELinux) are likely needed.
Hello Ulrich,
Thanks for taking time to respond !
On 9/16/07, Ulrich Drepper <[email protected]> wrote:
> On 9/16/07, Francis Moreau <[email protected]> wrote:
>> I'm a bit puzzled because vdso doesn't seem to be used on my fedora 7:
>> I just compiled a trivial program which just call gettimeofday() and
>> ld.so resolves this call with vsyscall's gettimeofday.
>>
>> Now I'm wondering when vdso is used, could anybody give me a clue ?
>
> F7 was released before the vdso for x86_64 was upstream so you should
> not expect anything else. F8 will use the available vdso. This
> doesn't just happen magically, changes to libc are needed.
>
You're right. I don't know why I thought vdso was older...
>
>> Another question: is vdso going to replace vsyscall at all ? If so how
>> are statically programs going to be handled ?
>
> Unfortunately the vsyscalls cannot ever go completely away.
> Statically linked apps, the bane of progress, will need them. There
> are also people updating kernels but not the user userland code.
>
Does that mean we'll need to keep 3 different implementations of gtod
in the kernel forever ?
> What we will have to do in future is to make vsyscalls configurable.
> Both a compile time option and a runtime option (perhaps also under
> control of SELinux) are likely needed.
I think signal trampolines will still need them too. So making
vsyscalls configurable doesn't seem to work, does it ?
I took a look to glibc-2.4 and it doesn't seem to use
__kernel_vsyscall vsyscall. Am I wrong ? If so could you point me
where it's used in the code ?
Another not so related question, hope you don't mind :)
I'm having hard time to understand how ld.so is working, specially the
dynamic symbol resolution after looking at the glibc code and reading
the ELF specification.
Do you know any others documents that could help ?
Thanks a lot.
--
Francis
On 9/17/07, Francis Moreau <[email protected]> wrote:
> Does that mean we'll need to keep 3 different implementations of gtod
> in the kernel forever ?
That's a question for the kernel maintainers to answer.
> I think signal trampolines will still need them too. So making
> vsyscalls configurable doesn't seem to work, does it ?
vsyscalls aren't used for that. We have a restorer in libc and could
easily use one in the vdso. That's what is done on x86.
On 9/17/07, Ulrich Drepper <[email protected]> wrote:
> On 9/17/07, Francis Moreau <[email protected]> wrote:
> > I think signal trampolines will still need them too. So making
> > vsyscalls configurable doesn't seem to work, does it ?
>
> vsyscalls aren't used for that. We have a restorer in libc and could
> easily use one in the vdso. That's what is done on x86.
>
Sorry for my ignorance but what' is 'a restorer' ?
--
Francis
On 9/16/07, Ulrich Drepper <[email protected]> wrote:
> On 9/16/07, Francis Moreau <[email protected]> wrote:
> > Another question: is vdso going to replace vsyscall at all ? If so how
It's weird, because it seems that vsyscalls are only done by x86_64,
all others archs have only vdso... so they seem to forget about
statically linked apps...
> > are statically programs going to be handled ?
>
> Unfortunately the vsyscalls cannot ever go completely away.
> Statically linked apps, the bane of progress, will need them.
Actually if we could easily retrieve the vdso in a process memory
mapping (through a new syscall or /proc/self/maps), it should be easy
for gcc/ld to statically links vdso functions into a statically linked
app, shouldn't it ?
--
Francis
Francis Moreau writes:
> On 9/17/07, Ulrich Drepper <[email protected]> wrote:
> > On 9/17/07, Francis Moreau <[email protected]> wrote:
> > > I think signal trampolines will still need them too. So making
> > > vsyscalls configurable doesn't seem to work, does it ?
> >
> > vsyscalls aren't used for that. We have a restorer in libc and could
> > easily use one in the vdso. That's what is done on x86.
> >
>
> Sorry for my ignorance but what' is 'a restorer' ?
When the kernel sets up the context for a user-space signal
handler, it needs to supply a return address (in a register
or on the stack). That's the restorer. The restorer points
to a stub that performs sys_{rt_,}sigreturn(). Depending on
architecture and kernel version, the restorer stub can be
defined by libc, or be provided automatically by the kernel.
On 9/17/07, Francis Moreau <[email protected]> wrote:
> Actually if we could easily retrieve the vdso in a process memory
> mapping (through a new syscall or /proc/self/maps), it should be easy
> for gcc/ld to statically links vdso functions into a statically linked
> app, shouldn't it ?
Nonsense. All the code which is in the vdso has a real implementation
in libc. No need to substitute. The vdso is only there to adjust a
program to the actual environment in which it is executed and not in
which it is built. Your suggestion would do the latter which is
complete and utter nonsense.