[PATCH 12/23] linux: Add helper function to optimize 64-bit time_t fallback support

[Adhemerval Zanella]

On 14/07/2020 05:20, Lukasz Majewski wrote:
> Hi Adhemerval,
> 
>> These helper functions are used to optimize the 64-bit time_t support
>> on configurations that requires support for 32-bit time_t fallback
>> (!__ASSUME_TIME64_SYSCALLS).  The idea is once the kernel advertises
>> that it does not have 64-bit time_t support, glibc will stop to try
>> issue the 64-bit time_t syscall altogether.
>>
>> For instance:
>>
>>   #ifndef __NR_symbol_time64
>>   # define __NR_symbol_time64 __NR_symbol
>>   #endif
>>   int r;
>>   if (supports_time64 ())
>>     {
>>       r = INLINE_SYSCALL_CALL (symbol, ...);
>>       if (r == 0 || errno != ENOSYS)
>>         return r;
>>
>>       mark_time64_unsupported ();
>>     }
>>   #ifndef __ASSUME_TIME64_SYSCALLS
>>   <32-bit fallback syscall>
>>   #endif
>>   return r;
>>
>> On configuration with default 64-bit time_t these optimization should
>> be optimized away by the compiler resulting in no overhead.
> 
> I think such approach was proposed in the very first Y2038 conversion
> patch done by Albert [1].
> 
> (By using __y2038_linux_support variable).

Thanks I didn't see this in fact.

> 
> 
> 
> I think that it is an overkill (or maybe I'm not aware of some
> important use cases) as new ports with __WORDSIZE==32 have already
> __TIMESIZE == 64, so they use 64 bit syscalls out of the box (RISC-V,
> ARC).

It should be a noop on newer 32-bit ports with 64-bit time_t, so no
overhead (as for any other 64-bit time_t  only ABI).

> 
> Moreover, systems with __WORDSIZE==32 && __TIMESIZE !=64 (like ARM)
> will benefit from it only when they use:
> 
> Old Linux headers (probably with oldest kernel supported - version
> 3.2) and Linux version < 5.1).
> 
> All new BSPs for them will probably use kernel > 5.1 (5.4 is the newest
> LTS), which will support 64 bit calls.

That's why I using this optimization only on specific symbols, I don't
foresee that it would be common for time64 binaries on old 32-bit abi 
with 32-bit time_t support would be deployed on pre v5.1 kernels.

In any case, I still think that this should be quite simple optimization
(the exempla above only adds about a couple of extra lines).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20200716/b5965f5b/attachment.sig>