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 9F9F33857009 for ; Mon, 7 Dec 2020 10:22:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9F9F33857009 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 4CqKBP2qRfz1qt4D; Mon, 7 Dec 2020 11:22:37 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4CqKBP1c8lz1qw5x; Mon, 7 Dec 2020 11:22:37 +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 LKpI-vmUfvXH; Mon, 7 Dec 2020 11:22:35 +0100 (CET) X-Auth-Info: 4uVt5iQxNXoMQY26RnRcU/uPNFVDG89CEzHj7CIyGGY= Received: from jawa (89-64-5-98.dynamic.chello.pl [89.64.5.98]) (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; Mon, 7 Dec 2020 11:22:34 +0100 (CET) Date: Mon, 7 Dec 2020 11:22:21 +0100 From: Lukasz Majewski To: Joseph Myers , Adhemerval Zanella Cc: Paul Eggert , Florian Weimer , GNU C Library , Siddhesh Poyarekar , Andreas Schwab , Stepan Golosunov , Alistair Francis , Carlos O'Donell Subject: Re: [RFC 0/6] y2038: Prepare glibc to be Y2038 safe for 32 bit ports Message-ID: <20201207112155.1106ca77@jawa> In-Reply-To: References: <20201204233604.7430-1-lukma@denx.de> 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_/RIVsBTd5tXPr_x_S3LWD.Pn"; protocol="application/pgp-signature" X-Spam-Status: No, score=4.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, SPAM_URI, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: **** 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: Mon, 07 Dec 2020 10:22:42 -0000 --Sig_/RIVsBTd5tXPr_x_S3LWD.Pn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Joseph, > On Sat, 5 Dec 2020, Lukasz Majewski wrote: >=20 > > This patch series is the RFC for preparing glibc to be Y2038 safe on > > ports with __WORDSIZE=3D32 && __TIMESIZE!=3D64 (e.g. 32 bit ARM). =20 >=20 > What exactly does "preparing" mean here? In this particular case - I meant that all the patches in this series are necessary to provide Y2038 support. Please also be aware that this is only the RFC. To be more specific - only patch 1/6 will be the "transitional" patch in a sense that after applying it the _TIME_BITS flag would be introduced and ready to be use by users. Patches following it - i.e. from 2 to 6 are added to show what is needed to tune glibc to have 64 bit time support. Those are mostly related to earlier 'stat' rework done by Adhemerval and shall be applied (or the problem shall be resolved in the other way) before patch 1/6 is applied. I just wanted to wrap all the necessary patches in a single patch series to show how much work is still necessary. >=20 > I'd expect support for _TIME_BITS to go along with public symbol > versions for all the new symbols that functions get redirected to, > because otherwise people building with _TIME_BITS=3D64 will get either > link failures or broken binaries depending on GLIBC_PRIVATE symbols. > But as far as I can see, this patch series only adds GLIBC_PRIVATE > symbols, not any public symbols or corresponding abilist updates. You are right - this was my omission. I've added those new symbols to GLIBC_PRIVATE as it was easier for maintenance. For the "final" version of this patch set I will add all those symbols to GLIBC_2.3X {}. >=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). 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. The time namespaces don't support CLOCK_REALTIME, and the only feasible way to do this is with re-using (and optimizing): test-wrapper=3D'/opt/glibc/src/scripts/cross-test-ssh.sh I'm also concerned how this work shall be divided - the patch which introduces _TIME_BITS flag would be very large and difficult to review. Would it be allowed to add tests (which would use _TIME_BITS) to glibc tree earlier? >=20 > You don't say how this series was tested, This patch set causes following Y2038 tests being all passed: https://github.com/lmajewski/y2038-tests/ Those tests are run as part of meta-y2038: https://github.com/lmajewski/meta-y2038/ Those are "simple" programs to test single syscall (e.g. clock_settime or stat) built with _TIME_BITS=3D64 and _FILE_OFFSET=3D64 and run on QEMU (arm32 bit vexpress-c15 board). This is the only way to be able to set future time after time_t overflow. > but this may be around the > point where build-many-glibcs.py testing is needed.=20 In the thread [2] - I've suggested such approach, but this would imply setting/changing time on the build host. To overcome this problem we would need time namespaces, but for now there is no plan to provide such functionality ([1]). > Certainly any > patch in such a series that adds a new public symbol should be tested > with build-many-glibcs.py to make sure that all the ABI test baseline > updates are correct. >=20 Would it be possible to test e.g. clock_settime64 if it sets correct time after 32 bit time_t overflow? Any other syscall would require time adjustment of host to properly test execution paths. Would you recommend extending build-many-glibc to also download, build qemu and run tests inside? In the discussion [1] it was pointed out that this would be a bit cumbersome.=20 Last but not least, just the "build" testing shall be provided with current setup as for e.g. __WORDSIZE=3D32 and __TIMESIZE!=3D64 (e.g. arm32 bit) we do use 64 bit interfaces anyway. Links: [1] - https://lore.kernel.org/lkml/20201114102503.GB1000@bug/T/ [2] - http://sourceware-org.1504.n7.nabble.com/Y2038-Question-about-porting-y2038= -tests-to-glibc-td652557.html 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_/RIVsBTd5tXPr_x_S3LWD.Pn Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl/OAl0ACgkQAR8vZIA0 zr0xWggAkBR9YBghOxL95opzAY791LPTVVoHcnt7phnKfIiXCtnaYLTj1MjLOdWG iadi3EGuhjfjtPhp2RPNx0GcilK6wydafl7iXCUUCv240+8RdsTWxqERwPzjoff4 jxk8s9YCus/LSvxF9sCu7l0IT7HfZnCl1knGpmnzgza0m8t1sepOyKi0aOueKRHC HHGrQhyIs2L0TLPAoIoMLSI1UDfhoNJPAgPHh4w8U8TBeZXsjN7GTGTecReHOyg0 jkJU3emChg8iXYk7s/cHl03eykN18qeso4j2QqvRF4yGxFf9SVMsp2rhrRWVxAQa z38oIhMIR0qqMk+TciQRpmnn3gCkvA== =EdFf -----END PGP SIGNATURE----- --Sig_/RIVsBTd5tXPr_x_S3LWD.Pn--