On Sun, 26 May 2019, Lukasz Majewski wrote:

> Shall the __ASSUME_TIME64_SYSCALLS be defined as:
> (@ sysdeps/unix/sysv/linux/kernel-features.h):
> 
> #if __WORDSIZE == 32
> # if __LINUX_KERNEL_VERSION >= 0x050100
> #  define __ASSUME_TIME64_SYSCALLS 1
> # endif
> #endif
> 
> And also for __TIMESIZE==64
> (@ include/time.h)
> 
> #if __TIMESIZE==64
> # define __ASSUME_TIME64_SYSCALLS 1
> #endif

__ASSUME_* should *only* be defined in kernel-features.h.  A definition in 
include/* would be incorrect.

It's not clear to me that __TIMESIZE == 64 would be the right condition 
(in kernel-features.h) for defining __ASSUME_TIME64_SYSCALLS independent 
of kernel version, because it would get wrong the case of 32-bit 
architectures with old kernel support and glibc support added in future 
with 64-bit time only (if we decide that any such future glibc port should 
use only 64-bit time in userspace, but without also requiring a new kernel 
for such a port).  Rather, __WORDSIZE == 64 (with a special case for x32) 
is, as previously discussed, closer to what we want (which is that the 
"long" in the syscall ABI is 64-bit, which corresponds to __WORDSIZE and 
the userspace "long" in all cases except for x32).

> Then the code would be (it is easier for me to understand the
> execution paths when providing the pseudo code):
> 
> __clock_settime64(....)
> {
> ...
> 
> #ifdef __ASSUME_TIME64_SYSCALLS
> #  ifndef __NR_clock_settime64
> #    define __NR_clock_settime64 __NR_clock_settime [1]
> #  endif
>   INLINE_SYSCALL_CALL (clock_settime64, …) [2]
> #else [3]
>   int ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
>   if (ret == 0 || errno != ENOSYS)
> 	return ret;

This part of the code inside the #else needs to be conditional, as well, 
on "#ifdef __NR_clock_settime64".  (Unless we require very new kernel 
headers to build glibc.  But we obviously can't right now - there's no 
existing kernel release whose headers both include these syscalls and are 
suitable for testing glibc, because of the fds_bits namespace issue.)

-- 
Joseph S. Myers
joseph@codesourcery.com