[RFC v2 07/20] sysdeps/gettimeofday: Use clock_gettime64 if avaliable

[Joseph Myers]

On Mon, 24 Jun 2019, Alistair Francis wrote:

> Not all architectures support the obsolete gettimeofday so use the
> newer clock_gettime64 syscall if it is avaliable. This fixes RV32
> build issues.

A key question when using newer syscalls to implement gettimeofday or 
settimeofday, which the commit message needs to answer, is: what are the 
semantics for how the obsolete tz argument is handled, if not NULL?

I'd expect the proposed commit message to include a discussion of what the 
semantics are for that obsolete argument in Linux kernel versions 
supported by glibc, and what the semantics are for that argument in glibc 
when some other syscall gets used by glibc.

For example, I'd expect that if tz is not NULL, any implementation using 
other syscalls would at least fill in some dummy values in *tz, if that's 
what the gettimeofday syscall would do.  And on architectures where the 
gettimeofday / settimeofday syscalls exist, if it is the case that some 
information gets passed from settimeofday to gettimeofday through this 
argument, I'd expect that information to continue to get passed through 
rather than being lost through the use of newer syscalls.  (You could 
reasonably argue for not supporting anything with that argument in the 
_TIME_BITS=64 case, but there could still be issues of keeping ABI 
compatibility for this argument for existing ABIs with 32-bit time, unless 
the current kernel semantics don't actually support doing anything with 
this argument anyway.  In any case, we need that explanation of current 
semantics in order to review any semantic changes from the patch.)

-- 
Joseph S. Myers
joseph@codesourcery.com