Hi Joseph,

> 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.

Ok, so if I understood you correctly - I shall devise tests, which can
be run as unprivileged user and if possible reuse existing tests with
_TIME_BITS=64 defined.

> 
> > 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).

Ok, I will prepare proper patch - as I do already have all the
redirections for already converted syscalls.

In that way we would avoid one bit patch, which would add _TIME_BITS
support.

> 
> I'm not sure if there is going to be any support for _TIME_BITS=64
> for Hurd

I've focused on the glibc ports, which use Linux as the kernel (mostly
ARM 32 bit). 

I do NOT have any plans to also support HURD.

> - the minimum requirement there is simply not to provide an 
> inconsistent ABI (so either no header redirections,

I would opt for the above option - no redirections for HURD.

> or all header 
> redirections operate and go to working functions) and not to break
> the build of glibc or the testsuite.

All exported headers' redirections are "protected" by:
"#ifdef __USE_TIME_BITS64"

And __USE_TIME_BITS64 will be only defined when _TIME_BITS=64 &&
_FILE_OFFSET_BITS=64 && __TIMESIZE != 64

I think that the most pragmatic approach would be for HURD to:

1. Introduce new header - ./sysdeps/hurd/include/features.h
2. In this file:

	#include_next <features.h>
	/*
	 * HURD is not (yet) supporting 64 bit time on archs with
	 * __TIMESIZE!=64 && __WORDSIZE=32
	 * For that reason we explicitly undefine the __USE_TIME_BITS64
	 */
	#undef __USE_TIME_BITS64

or even better:

	#ifdef __USE_TIME_BITS64
	# error "On i686-gnu HURD the _TIME_BITS flag is not supported!"
	#endif


In that way we would either silently disable Y2038 suport on HURD or
(preferable) prevent compilation with the error information.

> 
> > 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.

Ok. Thanks for the clarification.

> 
> 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.
> 

I could add / port / maintain the meta-y2038 on the sourceware.org or
Yocto, so people could use Y2038 safe glibc on embedded systems. For
now I do maintain it on GitHub:
https://github.com/lmajewski/meta-y2038/blob/master/README


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de