Re: Accelerating Y2038 glibc fixes

[Florian Weimer <fweimer@redhat.com>]

* Arnd Bergmann:

> b) Those that already need support for 64-bit time_t because
>     they are deploying new 32-bit binaries that are expected to run
>     beyond 2038, while not caring at all about compatibility
>     with existing binaries that are already known to be broken
>     for this purpose.

There is also c), new 32-bit architectures which need 64-bit time_t
support today due to kernel limitations.  Whether those binaries need to
run for two years or twenty does not matter to them.

I have reviewed patches for the c) case, but that doesn't seem to be
work that interests Wolfgang.

> Any of the above approaches (including the current plan of
> supporting time32 and time64 in a single glibc binary) can of
> coexist, but the more incompatible approaches get implemented,
> the more fragmentation of ABIs we get.
>
> Note that we have never had such a forced transition on x86,

We did change the stack alignment requirements on x86.  Without any ABI
markup.  For the non-executable stack, we used proper markup, but hat
approach will not work for time_t.

Several of the transitions you mentioned have ELF markup for the
transition, and at least in the case of ELF v2 for POWER, it is really
clear and consistent (it's also an easy scenarion admittedly, and very
different from the time_t situation).

Part of my reservations about the update to legacy ABIs is there hasn't
been any discussion about markup.  I'm not saying that we absolutely
need to have it.  It's just something that contributes to my general
unease.

Thanks,
Florian