[RFC v3 04/23] sysdeps/clock_gettime: Use clock_gettime64 if avaliable

[Adhemerval Zanella]

On 18/07/2019 05:18, Florian Weimer wrote:
> * Arnd Bergmann:
> 
>> I have two ideas for how that could be done:
>>
>> - When building for a minimum kernel version of 5.1, don't
>>   fall back to __vdso_clock_gettime() or syscall(__NR_clock_gettime)
>>   but use the slow path for __clock_gettime64() if the vdso doesn't
>>   work.
> 
> Assuming that clock_gettime64 support is available, yes.
> 
>> - if __vdso_clock_gettime64() is unavailable and __vdso_clock_gettime()
>>   returns negative seconds, fall back to syscall(__NR_clock_gettime).
> 
> I don't want to do anything like this.  I expect that some of us will
> eventually use time namespaces to keep programs running (with incorrect
> time).  If we make glibc itself time-sensitive, then things will get
> horribly complex.
> 
>> Would either of those meet your requirements?
> 
> I don't have requirements.  I just want something that has limited
> impact on 64-bit architectures.  I don't think probing at startup is too
> bad, actually.

I hope that my vDSO refactor patchset [1] may simplify the support.
For the patchset it just a matter of define the expected vDSO symbol
name (HAVE_CLOCK_GETTIME_VSYSCALL for time32), and then
{INLINE,INTERNAL}_VSYSCALL will check, demangle, call, and fallback
to syscall.

I would expect that for time64_t it would be a matter to just add
a new define, HAVE_CLOCK_GETTIME64_VSYSCALL, where each architecture
would define if were the case.  

[1] https://sourceware.org/ml/libc-alpha/2019-06/msg00344.html