Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries

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

On 01/02/23 19:22, Michael Hudson-Doyle wrote:
> On Thu, 2 Feb 2023 at 05:27, Florian Weimer via Libc-alpha <libc-alpha@sourceware.org <mailto:libc-alpha@sourceware.org>> wrote:
> 
>     * Sam James via Libc-alpha:
> 
>     > Right, it seems RH has some needs due to supporting existing
>     > customers, but I don't think this should unduly affect what glibc
>     > upstream does if there's one clear technical path forward. Nobody
>     > seems to actually dispute that the end-game here is a hard switch at
>     > some point. Just about when.
> 
>     I'm mostly worried about the glibc project issuing a statement that
>     distributions should change the i386 ABI of libraries layered on top of
>     glibc.  I don't quite see how this is in anyone's interest.
> 
>     What's the reason for a 32-bit x86 distribution at this point?  Support
>     for old hardware which can't run 64-bit binaries?  Running 32-bit
>     binaries which can't be rebuilt?  Optimizing the footprint of workloads
>     that fit into a 32-bit address space?
> 
> 
> The only reason Ubuntu still builds any packages on i386 at all is reason 2 here, to allow people to run old binaries that can't be rebuilt. As time passes the binaries that people care about are increasingly games. I presume for the cases where y2038 matters the default solution will be to run these binaries in a namespace that lies about the time.

It is an option, although I am not sure what might really work since afaik
Linux does not support CLOCK_REALTIME on time namespace.

> 
>     Only the first reason (old hardware on current distributions) can
>     justify the ABI bump.  And it's in direct conflict with the second
>     reason.
> 
> 
> Exactly.
>  
> 
>     For the third reason, it may be more approriate to revive the x32 port.
>     At least it doesn't interfere with legacy use.  There's a non-upstream
>     ILP32 port for aarch64, too, so the largely the same choice is available
>     over there (although 32-bit-only CPUs that may run glibc code are still
>     being manufactured in the Arm ecosystem, so the tradeoffs are different
>     over there, I assume).
> 
> 
> The 32-bit arm would is an entirely different calculation, yes. There are definitely devices being manufactured today that run Linux 32-bit that have the sort of expected lifetime that will bump into y2038 issues. I really hope the manufacturers have a plan! OTOH, there isn't a large pile of old armhf binaries lying around that people want to keep working in the same way there is on x86.
> 
> For people who use yocto or buildroot they should just start passing -D_TIME_BITS=64 and rebuild the world but general purpose, package based distributions have a more delicate dance to perform (FWIW, we don't have a fully fledged plan for Ubuntu yet but we're certainly starting to think about it).
>  
> 
>     My hunch is that the most likely outcome of switching distributions to
>     64-bit time_t is that the i386 port goes away more quickly than I would
>     expect otherwise because it makes the port rather useless for most
>     existing users (especially with those distributions that no longer
>     maintain a 32-bit-only kernel).  Personally, that wouldn't be a bad
>     outcome at all for me.  But I doubt that this is what people who push
>     for this change have in mind.
> 
> 
> Is anyone proposing that glibc will lose the ability to have the 32-bit time_t ABI? As you note that would kill the Ubuntu i386 port entirely (at some point this will probably happen anyway, people can always play their games in VMs but still).
>

Not really, there are some idea on how to proceed with 64 time_t promotion:

  1. Add a configure option to enable LFS and 64 bit time_t support as default.
     It is basically promoting the port to a new ABI, although a program can
     still build with non LFS or 32 bit time_t by explicit use -D_TIME_BITS=32.

  2. Make this option the default on a future glibc version, meaning that for 
     distribution that want to keep the the compatibility mode as default (to
     run old binaries) will need to explicit enable it.

  3. Move the non-LFS and 32 bit time_t symbols compat one, meaning that newer
     binaries won't be able to use them and -D_TIME_BITS=32 won't be supported
     or just be a no-op.

The 1 and 2 should not be cause many trouble, even if 2 would make 32-bit time_t
opt-in.  At least it would focused on glibc itself, meaning that a distribution
could just ignore the transition by just adding a configure option on glibc build.

The 3. is what might cause i386 (and any 32-bit port where ABI also supports
64-bit) to wither.  I don't have a strong opinion, maybe we should focus on
only the 1. and 2. and see what community things about 3.