Glibc 2.31 - time64 with 64-bit kernel and 32-bit userland

["Dr. Todor Dimitrov" <dimitrov@technology.de>]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

Hello,

we’ve recently updated an `aarch64` system to Glibc 2.31 and we’ve started seeing a lot of failing 403 and 407 syscalls. The kernel version is 4.1.52 and the userland is 32-bit. Looking at the implementation of `__clock_gettime64`, it seems that we are hitting the following problem:

  /* Old 32-bit ABI with possible 64-bit time_t support.  */
# ifdef __NR_clock_gettime64
  /* Avoid issue a __NR_clock_gettime64 syscall on kernels that do not
     support 64-bit time_t.  */
  static int time64_support = 1;
  if (atomic_load_relaxed (&time64_support) != 0)
    {
#  ifdef HAVE_CLOCK_GETTIME64_VSYSCALL
      r = INLINE_VSYSCALL (clock_gettime64, 2, clock_id, tp);
#  else
      r = INLINE_SYSCALL_CALL (clock_gettime64, clock_id, tp);
#  endif
      if (r == 0 || errno != ENOSYS)
	return r;

      atomic_store_relaxed (&time64_support, 0);
    }
# endif

`__NR_clock_gettime64` is defined for the 32-bit `arm` architecture but not for `aarch64`. Is this a known issue? What would be the best way to overcome it?

Thanks in advance,
Todor


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3895 bytes --]