Re: Accelerating Y2038 glibc fixes

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 25/07/2019 17:40, Joseph Myers wrote:
> On Thu, 18 Jul 2019, Adhemerval Zanella wrote:
> 
>> So what about to not add a user-selected way to set the time_t size
>> (as off_t) and just enable time64_t support and sets is as default for 
>> build with a minimum kernel of v5.1 (if I recall correctly as being the 
>> one that added time64 support)? 
> 
> I think duplicating ABIs like this is a very bad idea - the ABI supported 
> by glibc for a configuration that currently has 32-bit time_t should not 
> change to have two different, incompatible variants depending on how glibc 
> is configured.  The default API provided by glibc should also not vary 
> like that depending on how glibc is configured.

Later on the thread [1] I did state I would prefer switch based on release
rather than a configure option, the suggestion was initially as a way to
easier the transition (at the cost of complexity I give you).

> 
> Given that you have compatibility with existing binaries (as opposed to a 
> complete new incompatible libc.so.7 ABI with building libc.so.6 for that 
> architecture ceasing to be supported by glibc), eliminating support for 
> building with _TIME_BITS=32 makes the changes much *harder*, not easier.  
> There are three logical steps in the time_t transition.
> 
> (a) Support building applications for 64-bit time_t, using _TIME_BITS=64.
> 
> (b) Change the default to _TIME_BITS=64 (also requires defaulting to 
> _FILE_OFFSET_BITS=64).
> 
> (c) Remove support for building applications with _TIME_BITS=32.
> 
> The hardest of those steps is (c), not (a), because of the difficulty in 
> both building and testing all the compatibility symbols after step (c), 
> without all the header redirections of symbols getting in the way when 
> building those functions and the tests for them.
> 
> In view of the difficulty of both (c) and (a), it clearly makes sense to 
> separate them, and start with (a), with (c) to follow some time later.

Since we require to have both time32 and time64 implementation for the
'legacy' 32-bit architectures, the change to implement (c) is mainly to
make the symbol compat ones.  And since we will need to internal logic
to select whether to build time32 implementations (since for newer 32-bit
ABI time32 is not a option from kernel side and it does not make sense
to add time32 interfaces for such cases), the same applies for make them
a compat symbol.

The tricky part is testing, where it would require some more boilerplate 
to redirect to compat symbol instead of just define the _TIME_BITS, but
 with proper infrastructure on libsupport I still think this is feasible.

One extra step we will need to implement is to extend the abilist to take
in consideration whether the symbol is not the default version.

So I am not sure if (c) is really the most difficult part of the required
changes.

The question I have is what is the real gain of still supporting _TIME_BITS=32
as a build option, if the idea is default to _TIME_BITS=64.  It open a 
possibility to programs that are not time64 ready to just add _TIME_BITS=32
as a workaround, which is clearly *not* the desirable long-term desirable
option.

> 
>> I also wish we could also move forward with off_t and set LFS as default 
>> as well.
> 
> We can (it's the equivalent of (c), not of (b), that's particularly hard, 
> though even when doing (b) you need to be careful you keep sufficient test 
> coverage for both function variants).  See what I said in 
> <https://sourceware.org/ml/libc-alpha/2019-01/msg00124.html>.
> 

I recall the thread and your suggestion as the guideline to move forward [2].
However the getdents64 regression (BZ#23960) shows us that even after two
decades, at lot of environments still don't use _FILE_OFFSET_BITS=64 as default
and it most likely will take even more time to actually make it to land of
some projects.

This is most likely the usual usercases don't actually required LFS support and
only handful scenarios might trigger some issues with non-LFS support.  And
*now* is true for time_t interfaces as well, programs will continue to be build
and deployed with default options, or even worse, some pieces will be build
with different time_t abi which IMHO it even more difficult to debug. They will 
move forward to a safer ABI only when things start breaks.

So, different than LFS, I see no point in not moving forward to time64 and just
make time32 deprecated/compat.

[1] https://sourceware.org/ml/libc-alpha/2019-07/msg00456.html
[2] https://sourceware.org/ml/libc-alpha/2019-01/msg00177.html