From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 602EB398789D; Fri, 30 Oct 2020 17:09:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 602EB398789D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: vdpWrcF8Yj/91jXody1M5+Ydt9/n64c7DAbgsMp3tV7lyUCN3L2yrYRn7wpnbR8KqZhgARcY6o QUccwitkYXXpRWZhhBYM6a2mCQ/a5Cko0qs7Z0kKDaQFV8+Ojyqu99KXGhAI1RkDfY61CvirG0 78bScxs6X5l4otVIaLlITjGqJsFflhXLfVtyBn+iYM7GVGHXtYrVdDq4Rgh7D8fyio+U8V9hsO Me2+vWmJFzpo8esNmKhPBQIiGEZNbWPVgL1NitB5HnkxWoQ9GeMwIlGD19XzimNC09bGmWB90v qtk= X-IronPort-AV: E=Sophos;i="5.77,434,1596528000"; d="scan'208";a="54654497" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 30 Oct 2020 09:09:01 -0800 IronPort-SDR: SaAhg7HNtRhjErTZ2AOczViRPmoH2qkHGKMVTFxkPR2pM9zpCW6PbeSA8SUkJ4XEK2PnrwIt3h YMygJcJZvL/oQy2WL8Em8uXXK35l4Vdck2JsPr+Xm1qrkIJjMFHHcf5TWMyOCgClZfLBJfwYnM 6XmnDzQVY264/QT3HyEtvHfqc3/HF/GyYcmAyQGIbzzq0DK+MuyHud1mdETewe9043ZoAUocLk xM9lcwg8tEtVX1OTMg64D0nDLQHTaB2suXEZHR0fACjpYKqfjDP04EYLsi4KQvlbkCU6+ThRMc Fm8= Date: Fri, 30 Oct 2020 17:08:55 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Carlos O'Donell CC: Lukasz Majewski , Florian Weimer , , Andreas Schwab , libc-help , Alistair Francis Subject: Re: [Y2038] Question about porting y2038-tests to glibc In-Reply-To: Message-ID: References: <20201028110156.747fb676@jawa> <20201029104404.6b1fc1d7@jawa> <20201030104440.3bd26e0e@jawa> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-06.mgc.mentorg.com (139.181.222.6) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3125.8 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, 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 17:09:03 -0000 On Fri, 30 Oct 2020, Carlos O'Donell via Libc-alpha wrote: > 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. 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. -- Joseph S. Myers joseph@codesourcery.com