Re: [RFC 0/6] y2038: Prepare glibc to be Y2038 safe for 32 bit ports

[Joseph Myers <joseph@codesourcery.com>]

On Mon, 7 Dec 2020, Lukasz Majewski wrote:

> > I'd also expect support for _TIME_BITS to go along with tests
> > covering all the new interfaces (that is, for every time-affected
> > interface, there should be a test that it works properly with
> > _TIME_BITS=64, typically a test that defines _TIME_BITS to 64 then
> > includes an existing test for that interface, possibly with other
> > tests to verify that large time values work properly where possible).
> 
> This is a bit problematic as was discussed earlier [1] as we don't
> have the easy way to set host's (on which tests are running) time.

I'd like the _TIME_BITS=64 interfaces to be covered as well as the 
existing interfaces.  That is, test what can readily be covered with the 
existing testsuite infrastructure, but not things that require setting the 
system clock.  (You might be able to e.g. test sleeping for 2^32 seconds 
and interrupting that sleep after a second or two.)

E.g. pthread_mutex_timedlock / pthread_mutex_clocklock / mtx_timedlock are 
functions with a complicated implementation and several tests (in nptl/ 
and sysdeps/pthread/).  Whether or not there are further things to test 
specific to 64-bit time, it's definitely straightforward to add tests that 
define _TIME_BITS=64 then include one of the existing tests for one of 
those functions - so ensuring similar test coverage for both versions of 
each such function.

If any of the functions being changed aren't covered in the testsuite at 
all, but can be tested meaningfully as an unprivileged user, it would be a 
good idea to add basic tests of those functions that get run both with and 
without _TIME_BITS=64.

> Would it be allowed to add tests (which would use _TIME_BITS) to glibc
> tree earlier?

I think that's fine - certainly for tests which just define _TIME_BITS 
before including another test and will work for both 32-bit and 64-bit 
time_t.

The commit that causes installed headers to support redirecting interfaces 
when _TIME_BITS is defined to 64 should come last - there shouldn't be an 
intermediate state where a user defining _TIME_BITS=64 gets some 
interfaces redirected by installed headers and others not redirected.  
But before that final change to installed headers, there can be any number 
of preparatory commits (possibly including ones that add redirection 
support to individual headers, if the features.h patch that handles 
_TIME_BITS comes last).

I'm not sure if there is going to be any support for _TIME_BITS=64 for 
Hurd - the minimum requirement there is simply not to provide an 
inconsistent ABI (so either no header redirections, or all header 
redirections operate and go to working functions) and not to break the 
build of glibc or the testsuite.

> Would you recommend extending build-many-glibc to also download, build
> qemu and run tests inside?

My recommendation is simply to add those tests of the new interfaces that 
are reasonably straightforward within the existing testsuite and don't 
require running QEMU or changing the system clock or anything needing 
privileged access or unsuitable for running on a shared system.

Adding extra support for building and running QEMU should be considered a 
separate matter, quite possibly useful to help people test glibc patches 
more thoroughly where appropriate but not expected to be done as part of 
the Y2038 work.

-- 
Joseph S. Myers
joseph@codesourcery.com