From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by sourceware.org (Postfix) with ESMTPS id 710693854818 for ; Tue, 8 Dec 2020 10:08:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 710693854818 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=lukma@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4CqwqN5kJjz1qt3t; Tue, 8 Dec 2020 11:08:16 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4CqwqN4qmyz1tJP0; Tue, 8 Dec 2020 11:08:16 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id arRvVqIm0bij; Tue, 8 Dec 2020 11:08:14 +0100 (CET) X-Auth-Info: Ib+Fku6tCSu3XVAYvOmjh4p0ehCil4t+FS72gBEOW/8= Received: from jawa (89-64-25-12.dynamic.chello.pl [89.64.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Tue, 8 Dec 2020 11:08:14 +0100 (CET) Date: Tue, 8 Dec 2020 11:07:25 +0100 From: Lukasz Majewski To: Joseph Myers , Adhemerval Zanella Cc: Florian Weimer , GNU C Library , Siddhesh Poyarekar , Andreas Schwab , Stepan Golosunov , Alistair Francis Subject: Re: [RFC 0/6] y2038: Prepare glibc to be Y2038 safe for 32 bit ports Message-ID: <20201208110725.4e17a067@jawa> In-Reply-To: References: <20201204233604.7430-1-lukma@denx.de> <20201207112155.1106ca77@jawa> Organization: denx.de X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/GeroUu2i5HYK5b5a=vU36_L"; protocol="application/pgp-signature" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 10:08:20 -0000 --Sig_/GeroUu2i5HYK5b5a=vU36_L Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Joseph, > On Mon, 7 Dec 2020, Lukasz Majewski wrote: >=20 > > > 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=3D64, 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). =20 > >=20 > > 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. =20 >=20 > I'd like the _TIME_BITS=3D64 interfaces to be covered as well as the=20 > 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.) >=20 > 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=3D64 then include > one of the existing tests for one of those functions - so ensuring > similar test coverage for both versions of each such function. >=20 > 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=3D64. 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=3D64 defined. >=20 > > Would it be allowed to add tests (which would use _TIME_BITS) to > > glibc tree earlier? =20 >=20 > 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. >=20 > 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=3D64 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. >=20 > I'm not sure if there is going to be any support for _TIME_BITS=3D64 > for Hurd I've focused on the glibc ports, which use Linux as the kernel (mostly ARM 32 bit).=20 I do NOT have any plans to also support HURD. > - the minimum requirement there is simply not to provide an=20 > inconsistent ABI (so either no header redirections, I would opt for the above option - no redirections for HURD. > or all header=20 > 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=3D64 && _FILE_OFFSET_BITS=3D64 && __TIMESIZE !=3D 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 /* * HURD is not (yet) supporting 64 bit time on archs with * __TIMESIZE!=3D64 && __WORDSIZE=3D32 * 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. >=20 > > Would you recommend extending build-many-glibc to also download, > > build qemu and run tests inside? =20 >=20 > 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. >=20 > 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. >=20 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 --Sig_/GeroUu2i5HYK5b5a=vU36_L Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl/PUF0ACgkQAR8vZIA0 zr3kMggAudaa5SkU1xpyJTYsK0+7gz4dMLt5fI1isoBtHG/N8JQcfcI1iZQW34xe cUJ3AtVnj0+gX1Vct1q91P7cmq7y/ZuAfDglPebZ7xwa1Fy9ckJfhzDT8tBfcLRU cwmaL1ApuyZD3+NmWL/qhwHMj/UeJlydXMQfTQJcklZczGWFf9jyohn24r3T0OQo zf7QBNRGzfUInmgYd0CMTNGVjC7kEUTfmASBg4I3XF9ZMhvWP0H9GFYv4rPXuxEJ PgNXEW7c+rGx7g2lWbQFEnXuB10YLsRSydHoWEhBddcSpeAc+dpzbnsQIvqMhGz8 EUszRjpeYT5TrpIZEC+5rErrpYAbGQ== =weFw -----END PGP SIGNATURE----- --Sig_/GeroUu2i5HYK5b5a=vU36_L--