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 5BE63385782B; Fri, 30 Oct 2020 22:54:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5BE63385782B 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 4CNHgG71nKz1qs3k; Fri, 30 Oct 2020 23:54:18 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4CNHgG6KlHz1qvhF; Fri, 30 Oct 2020 23:54:18 +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 Ef-S6XpT424b; Fri, 30 Oct 2020 23:54:17 +0100 (CET) X-Auth-Info: D4+i3BiyIKwu/lsT/FBeXzlPHrH3WFZ9Ob7dYpmPkkw= Received: from jawa (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (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; Fri, 30 Oct 2020 23:54:17 +0100 (CET) Date: Fri, 30 Oct 2020 23:53:46 +0100 From: Lukasz Majewski To: Carlos O'Donell Cc: Joseph Myers , Florian Weimer , libc-alpha@sourceware.org, Andreas Schwab , libc-help , Alistair Francis Subject: Re: [Y2038] Question about porting y2038-tests to glibc Message-ID: <20201030235346.525fad70@jawa> In-Reply-To: <3e2beb53-b666-ead8-1876-fc085684d61d@redhat.com> References: <20201028110156.747fb676@jawa> <20201029104404.6b1fc1d7@jawa> <20201030104440.3bd26e0e@jawa> <3e2beb53-b666-ead8-1876-fc085684d61d@redhat.com> 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_/6scV+68cBlAuDw2uLmmT+1i"; protocol="application/pgp-signature" X-Spam-Status: No, score=-0.7 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-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 22:54:22 -0000 --Sig_/6scV+68cBlAuDw2uLmmT+1i Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Carlos, Joseph, > On 10/30/20 1:08 PM, Joseph Myers wrote: > > On Fri, 30 Oct 2020, Carlos O'Donell via Libc-alpha wrote: > > =20 > >> My technical opinion is as follows: > >> > >> * We should be open to expanding what build-many-glibcs.py does, > >> and providing options to select which operations are carried > >> out, including new QEMU tests. > >> > >> * Using QEMU user is OK in build-many-glibcs.py, but there may be > >> false positives due to QEMU emulation of syscalls because of the > >> host kernel. > >> > >> * Using QEMU system in build-many-glibcs.py is even better, and > >> would be a gold standard IMO. =20 > >=20 > > Options for those would be reasonable (they'd need to do the QEMU > > tests only for the subset of architectures and ABIs supported with > > QEMU), but getting to a clean baseline for even one of the > > supported glibc ABIs (thus, if using QEMU user emulation, > > annotating all the tests that might fail in such a configuration, > > reliably or randomly, because they use functionality such as > > threads and signals that's problematic for userspace QEMU - as well > > as the general matter of execution tests that may not reliably pass > > for all configurations) would probably be a lot of work. And a > > clean baseline is much better than needing to track known test > > failures individually. =20 > =20 > I agree. >=20 > I would accept QEMU usage in build-many-glibcs.py, and I also agree > that such checks must have a clean baseline. >=20 > Lukasz, Does this give you enough direction to pursue a solution? >=20 Yes. I think that we now have a good foundation to investigate the possible solution. Now, I do need to check if recent qemu-arm supports emulation of 64 bit time related syscalls (e.g. clock_settime64) in the "user mode". 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_/6scV+68cBlAuDw2uLmmT+1i Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl+cmXoACgkQAR8vZIA0 zr1nJwf/S77UxChHb8LCIQJmie/RbYz/ojCDvb+WXaZgwO/f2inwK5rX7Ay8UGx9 V1Pexnw5sFagCyGeDsRj0leGc2Ktpe6mMU/Lj5dPsYCRvSOYcglL6YX2+ZmTyxet 6bmn3NqHSunjBASIM2IeUiYPzamlMQRnAIve5tljWA1R9N0sODaqo300fOLe94J7 4pZcX0Ln1S1z18/6fFs9tUTXoUzcCwd7qzrrDWdq9CfQMj41AsN76Zvf9pyQce8G ZeXK3zZOQCVMnhvOo9XEkakBySZWITsPhKUEf18vaG7ml/nJ2EhCNYhpJzVPWkzD U4Oe2xXz3awQGOem8rd9aIt5iLKkQA== =YcX3 -----END PGP SIGNATURE----- --Sig_/6scV+68cBlAuDw2uLmmT+1i--