This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v3 02/23] sysdeps/gettimeofday: Use clock_gettime64 if avaliable
On Wed, Jul 17, 2019 at 09:09:08AM +0200, Florian Weimer wrote:
> * Alistair Francis:
>
> > diff --git a/sysdeps/unix/sysv/linux/gettimeofday.c b/sysdeps/unix/sysv/linux/gettimeofday.c
> > index a74f03825a..151b1e606c 100644
> > --- a/sysdeps/unix/sysv/linux/gettimeofday.c
> > +++ b/sysdeps/unix/sysv/linux/gettimeofday.c
> > @@ -32,7 +32,35 @@
> > int
> > __gettimeofday (struct timeval *tv, struct timezone *tz)
> > {
> > +#ifdef __ASSUME_TIME64_SYSCALLS
> > + int ret;
> > + struct __timespec64 now;
> > +
> > + ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
> > + &now);
> > +
> > + /* Convert from timespec to timeval */
> > + tv->tv_sec = now.tv_sec;
> > + tv->tv_usec = now.tv_nsec / 1000;
> > +
> > + return ret;
> > +#else
> > +# ifdef __NR_clock_gettime64
> > + long int ret;
> > + struct __timespec64 now;
> > +
> > + ret = INLINE_VSYSCALL (clock_gettime64, 2, CLOCK_REALTIME,
> > + &now);
> > +
> > + /* Convert from timespec to timeval */
> > + tv->tv_sec = now.tv_sec;
> > + tv->tv_usec = now.tv_nsec / 1000;
> > +
> > + if (ret == 0 || errno != ENOSYS)
> > + return ret;
> > +# endif
> > return INLINE_VSYSCALL (gettimeofday, 2, tv, tz);
> > +#endif
> > }
>
> This loses vDSO acceleration if glibc is compiled with kernel headers
> which define __NR_clock_gettime64, but the run-time kernel does not have
> clock_gettime64 in the vDSO.
>
> And the kernel folks really want us to call clock_gettime when the user
> calls the 32-bit function, for tracability of legacy processes.
May or may not be relevant to glibc plans, but I want to chime in to
mention that this (kernel tracability of legacy processes) is not
going to work with musl, except possibly static-linked programs with
old libc. Our legacy compat functions are just going to be thin,
implementation-agnostic wrappers around the new functions, so even if
a program is still calling the old clock_gettime symbol with 32-bit
timespec, it's going to be executing the new one as its backend, and
thereby calling the 64-bit syscall or vdso if available.
In the case of new libc with old application on old kernel, there will
actually be two conversions: 32->64 in the core (new) function after
the 64-bit syscall fails with ENOSYS and we fallback to the old
syscall, and 64->32 in the old-ABI-compat wrapper. This is a
consequence of not duplicating functionality and ending up with two
versions of everything to maintain, and also avoids incentivizing
continued use of the old ABI for users with old kernels (as a way to
bypass conversion costs).
In any case, just grepping dynsym tables for references to legacy
symbols seems like a more effective way of finding problems than
grepping for syslog spam...
Rich