Re: Accelerating Y2038 glibc fixes

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 29/07/2019 16:58, Joseph Myers wrote:
> On Mon, 29 Jul 2019, Adhemerval Zanella wrote:
> 
>>> 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).
> 
> I'm not clear what "switch based on release" means.

To make the time_t change its type on a new glibc release rather than the
configure option.

> 
>> 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
> 
> No, it's mainly (for a large number of functions) finding some way to 
> avoid the unconditional (for platforms with __TIMESIZE == 32) header 
> redirects from <func> to __<func>_time64 applying to the definitions of 
> those compat symbols (and, likewise, for all the functions that have 
> variants for _FILE_OFFSET_BITS=32, because we don't want to support the 
> combination of 32-bit offsets with 64-bit times, and requiring 64-bit 
> times implies first requiring 64-bit offsets).  You can do that with a 
> suitable #define before including the header and #undef after, but there 
> are many functions, and different implementations of those functions to 
> deal with - and then there is the testing issue, where the changes are 
> probably even more involved.
> 
> Just adding new function variants with new names and header redirection to 
> provide optional support for using them is much simpler than anything that 
> also obsoletes the old functions.

I think it would be easier than what you described because we won't need
to actually to add any header redefinition, all symbol affect will just
use the new time_t regardless of the ABI.  The compat implementation will
use an internal-only type to use the old one.

What it would require is to add compat implementations with a different
type, time32_t for instance.  Something like:

---
* sysdeps/unix/sysv/linux/generic/bits/typesizes.h
[...]
#define __TIME_T_TYPE           __UQUAD_TYPE
[...]

* time/time.h
[...]
extern time_t time (time_t *__timer) __THROW;
[...]

* sysdeps/unix/sysv/linux/time.c
[...]
time_t
__time (time_t *t)
{ 
#ifdef __ASSUME_TIME64_SYSCALLS
  return INLINE_SYSCALL_CALL (time64, t);
#else  
  int ret;
# ifdef __NR_time64
  /* Maybe we can use 'sets' of 'supported' to enable/disable
     multiple syscalls.  */
  static int time64_supported = 1;
  if (atomic_read_relaxed (&time64_supported) == 1)
    {
      ret = INLINE_SYSCALL_CALL (time64, t);
      if (ret == 0 || errno != ENOSYS)
	return ret;

      atomic_store_relaxed (&time64_supported, 0)
    }
# endif /* __NR_syscall64  */
  
  ret = INLINE_SYSCALL_CALL (time, t);
  /* I assume kernel will return EOVERFLOW if the case.  Other symbol
     will require further handling.  */
  return ret;
#endif
}
libc_hidden_def (time)

/* At first it would be a arch-specific definition, on kernel-features.h.
   Maybe there is a clever way to accomplish it.  */
#ifdef __REQUIRE_TIME32_COMPAT
/* Define time32_t internally somewhere.  */
time32_t
__time32 (time32_t *t)
{
  return INLINE_SYSCALL_CALL (time, t);
}
compat_symbol (libc, __time32, time, GLIBC_2_0);
versioned_symbol (libc, __time, time, GLIBC_2_SOMETHING);
#else
weak_alias (__time, time)
#endif
[...]
---

I used the simplest symbol I can think off, other symbol that use time_t embedded
inside more complex struct will need to replicate it on some compat header (as
we do for some internal definition such sigaction).

Testing will require more boilerplate to link against the compat symbol, but
we already have some support on libsupport and I think we can improve to
make it simpler.

> 
>> 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 
> 
> The gain is supporting building glibc itself for such configurations 
> without a large amount of complicated work to build and test compat 
> symbols needing to be done up front - allowing the transition to be broken 
> down into more reasonably sized pieces.
> 

I don't have a strong opinion if a patch proposal use the _TIME_BITS=32
as a initial transition to enable time64 support, however I see no point
in make it available either on a release point neither in long term. 

In fact I see that support_TIME_BITS=32 on long term is a detriment for 
the ecosystem as whole. It is error prone, it will be glibc specific 
(since other system that used to have the same issue already did that
transition without similar complexity, such as BSD), and it will lead 
to subtle bugs with the multiple build systems that we have in Linux 
ecosystem.

That's why I still think that an initial rough transition now to move
forward definitely is better than still support broken interfaces 
indefinitely (not considering the required compat implementations).