This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]