Re: Fourth draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Thursday, June 23, 2016 4:56:00 PM CEST Joseph Myers wrote:
> On Thu, 23 Jun 2016, Arnd Bergmann wrote:
> 
> > Is there a policy about what justifies such an ABI break? I.e. is it
> 
> The clear implication from the discussions around C++11 support in 
> libstdc++, which resulted in the complicated ABI tag infrastructure, is 
> that changing the libstdc++ SONAME would now be too costly, which implies 
> the same for the libc SONAME.  That is, incompatible ABIs may be 
> introduced with new ports (including fundamentally different 
> function-calling ABIs on an existing architecture), so under appropriate 
> SHLIB_COMPAT conditionals, but we don't expect to make such changes on 
> existing architectures (although as developers, it would be beneficial if 
> we could change the libc and libstdc++ SONAMEs say once a decade and get 
> rid of accumulated ABI peculiarities at that point - the problem is the 
> effects of such transitions on users).
> 
> > possible to add a build-time configuration flag later that disables
> > 32-bit time_t support for an existing architecture while setting
> > a different SONAME, assuming there is sufficient user interest for
> > this feature? I see a couple of different options that change SONAME
> > on https://sourceware.org/glibc/wiki/ABIList, but those are all
> > for fundamental incompatibilities, not for voluntary ABI breaks.
> 
> We got rid of --enable-oldest-abi as being extremely bitrotten.  I don't 
> think new options for such incompatibility are likely, at least absent 
> clear evidence of maintainability (and maybe builtbots using them, etc.).  
> It is of course possible to use function lists developed in the course of 
> designing and implementing _TIME_BITS=64 to produce a list of ABIs 
> involving 32-bit time_t, which could be used to validate that a binary 
> doesn't use such ABIs.  And a configuration option to turn the symbols 
> into compat symbols wouldn't break the ABI - it would be more like 
> --enable-obsolete-rpc.

Thanks for the detailed explanation!

I think having a switch to turn the 32-bit time_t calls into compat
symbols would be great. For the goal of guaranteeing that all code
has been built with the _TIME_BITS=64 flag it's almost as good
as removing 32-bit time_t from the build entirely, and not having
to break SONAME gives a migration path for those that want it.

If we introduce that option, this would both mark the symbols
as compat and also change the default for time_t to a 64-bit type
without requiring an explicit _TIME_BITS=64, right?

Anyway, I don't think we need this configuration option right away,
but it may be good to document in the wiki that this would be
something that can be implemented if users ask for it.

For making sure we break runtime support on old binaries when we
want to, running on a kernel that has the old syscalls disabled
is probably sufficient, and we will need that kernel feature
anyway, but it doesn't capture the case where you have a library
that wraps a time_t based interface but doesn't have symbol
versioning itself and a caller gets built against the library
with a conflicting flag. 

	Arnd