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 2E4EC3857C4A for ; Thu, 16 Jul 2020 17:33:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2E4EC3857C4A 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: L2X5VKPFUi8HubpazipRGOUx6yVm1U8VW9c6XYm7iIwGZvYgBZNy0tdx5X7TSs/2fZGNohXJLD 8Yq818/pew77EXmQQA4bxS7P2kUubl3TEr42Rm2jVIfShJhX9swgMjcl1tMsDq4M2jg8ZqTqDy oYh32prT9Z7H8+YtBQ0Lvx0A452zo6yXulmm4OeGD557emzQ3cjDU+dGO/V78VDQMBGU0Bnaq2 MfmV1CmBNtDJ4ec8EjksuBbjKUDZpEu4vZlTYwjR6P88E8sEFteCRrQx9Dmls6XretaJ4HyvcZ gUg= X-IronPort-AV: E=Sophos;i="5.75,360,1589270400"; d="scan'208";a="51117049" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 16 Jul 2020 09:33:33 -0800 IronPort-SDR: GhMuIS+Eh7ttWDxKbbxYVMKRqihr6uP/B2UOZmcV/NTospX9gkZK+HbIBikRSOvmQnFqv8d/vd 5z+sZorWJiVixE0qpAA/S/8l+kA+xJhSwgwYafEnIlkDRYF1K1PwIcdgubdadBJR5seL0sA2Sb bU6lg/0C8ZZBe0iUYL2tROdzFW6kYMi86I1cNKFD1GNtUrq8MuWpTIojhgvO5DIy3NvhSPUI9u M3K3QsUJyHFx3s9DEYFFHdcbTGpNORjdjfcxCVOnPATptXpLLisICGHdZZH+8DFAGlN7E+ppAM FOg= Date: Thu, 16 Jul 2020 17:33:28 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Caroline Tice CC: Caroline Tice via Gdb-patches , Eric Christopher , Tom Tromey , Simon Marchi Subject: Re: [PATCH] Update testsuite mechanism to allow object files as source files. In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-08.mgc.mentorg.com (139.181.222.8) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3129.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 17:33:36 -0000 On Thu, 16 Jul 2020, Caroline Tice via Gdb-patches wrote: > High level summary: > In some (hopefully rare) cases, certain tests MUST be built with a > particular compiler to work. If that compiler is not GCC, then it > makes it very burdensome for developers to run the GDB testsuite and > test those tests. This change allows those tests to use object files > (generated by the required compiler) as the test source file, so that > when the test suite is run with GCC those tests will still > execute/test properly. How is this expected to work when the GDB being tested is configured for a different architecture or OS from that of the checked-in object file and may not be able to read its object file format at all? Will all such tests have explicit conditioning on the target for which GDB is configured? On general free software and reproducible builds principles: * The source for any checked-in object file should be checked in. * That source should include comments giving all information required to be able to reproduce the object file byte-for-byte - for example, the exact git commit of the compiler used to generate it, the exact options with which that compiler should be configured and the exact command line to use with that compiler to generate that object file. And it should have been verified by someone in a different environment from the person proposing the addition of such an object file that following those instructions does give a byte-for-byte identical object file. -- Joseph S. Myers joseph@codesourcery.com