From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id CBEA21F45E for ; Thu, 20 Feb 2020 13:15:43 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; q=dns; s=default; b=QDv8p HPZtfmHcj0TURb1eOAOCU+8IbA4BFWJVyd8TH7KFA1DSB5WtfliFdI3zNusqNIAD 6EBcC6BibGtSAl9X91HpxD5D4WTNQzfCu4bV2wcS6z9xmq5QwIS7PmNPFKuR8LzZ sU31r934XkYIZfzRgVmOU6rbIgJon5w/Uk3/tg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type; s=default; bh=3CotE7Y2K+C 8IpTBPmIdw5HT+JU=; b=kbYRY2GEhdbC+yTW0nkiYg+WSYXuq/obqPb+4qeiOcv EUy2Ynx6OwMXRSQlxjKuUM4m6Fm5SlBEw8rLMUt+e1KohPbn8+tv7GHeliBTtQ8l M90Etq0G7chDAI47779ahb2CbpGT8/T55sSBhMHZ2v94VJxpmtEd7BAYEvdt1jXc = Received: (qmail 104704 invoked by alias); 20 Feb 2020 13:15:36 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 104334 invoked by uid 89); 20 Feb 2020 13:15:07 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-out.m-online.net Date: Thu, 20 Feb 2020 14:14:51 +0100 From: Lukasz Majewski To: Arnd Bergmann Cc: Vineet Gupta , Alistair Francis , Joseph Myers , Florian Weimer , GNU C Library , Palmer Dabbelt , Zong Li , Alistair Francis , Adhemerval Zanella , "Maciej W. Rozycki" , arcml , debian-arm@lists.debian.org, Helmut Grohne Subject: Re: switching ARC to 64-bit time_t (Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64) Message-ID: <20200220141451.3fa2fc3f@jawa> In-Reply-To: References: <4e95f95966d8d7c6a8339160dc62d81c1f6a1bfb.1578824547.git.alistair.francis@wdc.com> <00574bfb-981a-3a1c-cbdf-b2fee4eddc32@gmail.com> <8a9784b3-fc52-adc3-4595-33142b059388@synopsys.com> <20200220001136.2f14236e@jawa> <20200220103716.2f526933@jawa> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/.Lr44PqzF.BjZHvWSRoYEZo"; protocol="application/pgp-signature" --Sig_/.Lr44PqzF.BjZHvWSRoYEZo Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Arnd, > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski > wrote: > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski > > > > > > Would it be possible to take a snapshot of your glibc tree =20 > > > > The description of the status of Y2038 supporting glibc on ARM 32 > > can be found here [1]. > > > > The most recent patches for Y2038 supporting glibc can be always > > found in the 'y2038_edge' branch [2]. =20 >=20 > Ok. >=20 > > > and start testing this out with debian-rebootstrap [1]? =20 > > > > I've been using OE/Yocto for testing as it allows building glibc > > sources for x86_64, x86, x86-x32, arm32 (probably also for ppc32 and > > mips - but not tested). > >... > > However, I did not yet tried debian-rebootstrap. I will look if this > > can be reused as well. =20 >=20 > The reason I'm asking about debian-rebootstrap is less about testing > glibc itself than about testing the rest of user space to figure out > better what needs to be done when rebuilding with _TIME_BITS=3D64, and > to start fixing more upstream packages, with the hope of having enough > of it done in time for the Debian 11 release. Ok. I see. Thanks for the information. Validating the packages was one of the reasons to move from some custom made test images/setup to Yocto/OE (as it is very close to customers needs). >=20 > > > Are there any glibc issues that prevent it from working > > > correctly, =20 > > > > I think that the glibc wrappers for most important syscalls are now > > converted. > > > > What is missing: > > > > - NTPL (threads) > > - stat =20 >=20 > Do you mean that code using these will fail to work correctly with > -D_TIME_BITS=3D64 at the moment, or that the interfaces are there > but they are not y2038 safe?=20 For ARM32 (branch [2]): - Without -D_TIME_BITS=3D64 defined during compilation (as we do have now) the glibc is fully functional, but when you set date after 03:14:08 UTC on 19.01.2038 you will see the date reset (to 1901) in the user space programs (after calling e.g. 'date'). - With -D_TIME_BITS=3D64 set during compilation - and using branch [2] - syscalls listed in [1] will provide correct date after Y2038 32 bit overflow. Other (i.e. not converted ones) will use overflow date (1901 year). The glibc will also be fully functional up till Y2038 overflow. > Without pthreads or stat, we probably > wouldn't get too far in rebootstrap, but if the interfaces are there > and mostly work, then we don't need to rely on them being > y2038-safe just yet. According to my above statement the second assumption is correct. > An obvious next step would be to run the > resulting code with the RTC set 20 years ahead, and that requires > it all to work. Yes. This is what I do for the test setup [3]. I do use clock_settime syscall (now it is working correctly) or just 'date' from user space. >=20 > > - In-glibc test coverage when -D_TIME_BITS=3D64 is used. I do have > > some basic tests [4], but this may be not enough. =20 >=20 > This is probably something where debian-rebootstrap could help, > as building and testing more user space packages will excercise > additional code paths in glibc as well.=20 Yes this _could_ help. Do you have any tutorial/howto similar to one from [4]? I also think that some tests from debian-rebootstrap could be moved to glibc test framework (test suite). For example tests for clock_settime/gettime/nanosleep/ etc. In that way the glibc-many-build.py would run those tests for all supported ports. Then the debian-rebootstrap could test for more sophisticated bugs (like dependencies between syscalls, etc). > There is also some work > in Linaro to ensure that LTP tests the low-level syscall interfaces > in both the time32 and time64 variants. Interesting. Is this work now publicly available? >=20 > Arnd Links:=20 [1] - https://github.com/lmajewski/y2038_glibc/commit/4f72f695d1ac428fe945cd7d5e9= 5770180d4a7c1 [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge [3] - https://github.com/lmajewski/y2038-tests [4] - 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_/.Lr44PqzF.BjZHvWSRoYEZo Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl5OhksACgkQAR8vZIA0 zr2gTAf+JuLaN3cAoCJLs4ti/DWz7x0bhfRs8RnT84ngE3shi10/lvHZHb5DBNx6 B79cUxqKPVTRqp3+aF4cjwXbTIs3SWrHJK2cciYU1W8STu5B0Ge0NKMwHey5m5Ks 81dVBi+PJl2E9iDjQoTEgwqJA808oGP+dpu9QJZpVye9bhTxdS/jFeN/ddZ3yNsr hs7kdtSYnBbfbkIk8yuPSIkFKWZSpzEVeDnNVVZlX7dYwzrb1DyAnHwqAhSYkT13 sC+kCiJf06lfKd4WI3kFEIKz0VsZ2uWNcgEID0nQyhFvl4qD6CSkTWwKEUUHXW16 /37pfVMA9KXPz1MVcaicyvVwIiExFA== =jcs8 -----END PGP SIGNATURE----- --Sig_/.Lr44PqzF.BjZHvWSRoYEZo--