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 Fri, 19 Jul 2019, Rich Felker wrote:
> > 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.
And as far as I'm concerned glibc should do likewise (I have a sustained
objection to duplication of nontrivial function implementations at either
the source and binary level for time_t variants when thin wrappers would
do the job just as well, given the principle that the particular choice of
syscalls for a given function is not a stable interface). (Where a
function is defined entirely in syscalls.list, it might continue to use
the old syscall, subject to working out the best way to set up function
aliasing for that case.)
> 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...
Yes.
--
Joseph S. Myers
joseph@codesourcery.com