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

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella via Libc-help:

> This is the expected behavior, running this small example:
>
> --
> #include <time.h>
>
> int main (int argc, char *argv[])
> {
>   clock_gettime (CLOCK_REALTIME, &((struct timespec) {}));
>   clock_gettime (CLOCK_BOOTTIME, &((struct timespec) {}));
>   return 0;
> }
> --
>
> On a aarch64 kernel without 64-bit compat time_t support (4.12.13),
> this is the generated syscalls:
>
> --
> clock_gettime64(CLOCK_REALTIME, 0xfffebb58) = -1 ENOSYS (Function not implemented)
> clock_gettime(CLOCK_REALTIME, {tv_sec=1610997887, tv_nsec=516302599}) = 0
> clock_gettime(CLOCK_BOOTTIME, {tv_sec=2750059, tv_nsec=271773400}) = 0
> --
>
> The catch here the 64-bit kernel when running 32-bit userland will
> use compat entrypoints to provide the expected kernel ABI. For kernel 
> older than v5.1, it means that even if kernel is 64-bit and support 
> 64-bit time_t, the 32-bit syscall entrypoints won't have 64-bit time_t
> support.

Ugh.  Is this for ILP32 support?

Should we just undefined __NR_clock_gettime64 for 64-bit AArch64?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill