Glibc 2.31 - time64 with 64-bit kernel and 32-bit userland
Adhemerval Zanella
adhemerval.zanella@linaro.org
Mon Jan 18 20:31:12 GMT 2021
On 18/01/2021 17:14, Florian Weimer wrote:
> * 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?
No, this is armhf default binaries. This situation is similar to
i686 running on x86_64 kernels.
AArch64 (and any other architecture with default 64-bit time_t)
will build Linux clock_gettime.c as:
int
__clock_gettime64 (clockid_t clock_id, struct __timespec64 *tp)
{
int r;
# define __NR_clock_gettime64 __NR_clock_gettime
if (true)
{
r = INLINE_VSYSCALL (clock_gettime64, 2, clock_id, tp);
if (r == 0 || errno != ENOSYS)
return r;
}
return r;
}
More information about the Libc-help
mailing list