This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] ppc64 vdso
- From: Roland McGrath <roland at redhat dot com>
- To: Benjamin Herrenschmidt <benh at kernel dot crashing dot org>
- Cc: libc-alpha at sources dot redhat dot com,Steve Munroe <sjmunroe at us dot ibm dot com>,Alan Modra <amodra at bigpond dot net dot au>
- Date: Fri, 5 Nov 2004 19:13:40 -0800
- Subject: Re: [PATCH] ppc64 vdso
Your vDSO linker script should provide a version script to specify the
exports of your DSO (which should be stripped). See
arch/i386/kernel/vsyscall.lds.S for an example (but you should not use
LINUX_2.5, but instead LINUX_2.6.10 or whatever upstream release number
your vDSO will first appear).
> - Signal trampolines. (__v_sigtramp_rt64, __v_sigtramp_rt32, __v_sigtramp32).
> I don't think glibc need to directly access those symbols, the kernel will
> setup the signal return address to them, they provide the necessary cfi infos
> to make the exception unwinding happy (thanks Alan Modra).
That's correct.
> - _v_get_syscall_map(). the prototype of this is
We have nothing that would use this as yet. It would not be a great deal
of work, though a bit intricate, to make use of this for the various places
where we now sometimes try system calls and fall back when they are
missing. But we won't have any motivation to do that until there are
platforms using this to make useful distinctions not made now.
> - _v_gettimeofday(), same prototype as gettimeofday(), that is:
Can you provide nanosecond (i.e. struct timespec) access as well?
And to the CLOCK_MONOTONIC as well as the CLOCK_REALTIME clock, ideally.
> - __v_get_datapage() is for internal use by the vdso (hence the 2 underscores),
> used to access the last page of the vDSO which is shared with the kernel
> and contains various things used by gettimeofday or other future routines
> that will end up in the vDSO.
Such a thing should not be exported and is not the business of userland at all.
It's purely an internal implementation detail of the DSO.
But out of curiosity, why do you need it? Why aren't those just normal
TOC-relative accesses like the C compiler would generate for you?