From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.hgst.iphmx.com (esa2.hgst.iphmx.com [68.232.143.124]) by sourceware.org (Postfix) with ESMTPS id C8D3A383F86B for ; Wed, 10 Jun 2020 16:37:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C8D3A383F86B IronPort-SDR: Kldagwe34sOG4YEoLYZLfismTp+h9DiUr9FEOxBAIkPmwY/rf/cLay/Q8d96nxdab10fHVRXlB 5JBcQ4iZ7PMtkwwdIpCt5ugicvkLV6asRhrig05MCRoghU5UKvlX5270IeGErK55GLbHfpSIMF QdCDnyx9xtAFvibk4kK0FltUdGgzUbvvgddPmvZL6086vurw1l5iRXMXXdxmD+E1X6KCD4fzFi Uk+6YnfJF0utv/thGERS/iJgrJvdum9sWxamWMZX1KGbhO3E/iUW7oqvEK8QO0v6KZaijpQVZy ftQ= X-IronPort-AV: E=Sophos;i="5.73,496,1583164800"; d="scan'208";a="242566721" Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 11 Jun 2020 00:37:27 +0800 IronPort-SDR: 7NxmnS2pdrjI8nnWfsQVJju1wcH0Fa/QAWTak7gBZlq2ORZENqdEMNJGyi2NfAI+sUg7z58DjK 0QLQcMbCJvm5gRJ7JAOdXkqlO06MBT4gs= Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2020 09:26:34 -0700 IronPort-SDR: 085zYFSEhevTKBD2+3YmequMPc4PR1M4Le7PPV+uZCUZiZgtg7NkigO0mlZzX9U6j5dh+hGDUg asa6LnblE+GA== WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2020 09:37:06 -0700 Date: Wed, 10 Jun 2020 17:37:02 +0100 (BST) From: "Maciej W. Rozycki" To: Jacob Bachmeyer cc: Joel Brobecker , Rob Savoye , Jacob Bachmeyer , Siddhesh Poyarekar , Rainer Orth , gcc@gcc.gnu.org, Mike Stump , Thomas Schwinge , gdb@sourceware.org Subject: Re: dejagnu version update? [CORRECTION: not a regression in DejaGnu; GDB testsuite bug] In-Reply-To: <5EE05F15.4070408@gmail.com> Message-ID: References: <87zhac871g.fsf@euler.schwinge.homeip.net> <274e2a71-ddb0-18cc-70c1-4ca9ccf8bd29@welcomehome.org> <9a017568-911d-9352-859a-8721b2f47c53@welcomehome.org> <29b3fe32-b3c9-653e-2ef3-6e89083188f6@welcomehome.org> <3e294014-8205-c99c-ecc7-3e9d383e5587@welcomehome.org> <5EE04696.8090209@gmail.com> <5EE05F15.4070408@gmail.com> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=unavailable 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 16:37:10 -0000 [cc-ing Joel as the originator, and ] On Tue, 9 Jun 2020, Jacob Bachmeyer wrote: > >> I ran a quick bisection and the culprit turned out to be: > >> > >> ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit > >> commit ba60272a5ac6f6a7012acca03f596a6ed003f044 > >> Author: Jacob Bachmeyer > >> Date: Mon May 25 08:40:46 2020 -0600 > >> > >> Establish a default C compiler by evaluating [find_gcc] if no > >> other compiler is given. > >> > >> So this regression has to be fixed before any new release is made. > > > > I will look into this. So far, I have confirmed that the problem does > > occur and that setting the "compiler" board_info key in > > baseboards/unix.exp seems to avoid it. It looks like the default is > > not being selected in all cases where it should be used. I still need > > to find the exact problem to write a regression test to isolate this > > bug and make it stay squashed. > > After further efforts, and a few hours wasted trying to figure out why > additional tracing code added to default_target_compile was not > producing output, I eventually decided to just make > default_target_compile throw a Tcl error -- and I did not get a Tcl > error when running the tests... > > That is "very interesting" and a quick grep -R reveals the culprit: the > GDB testsuite is overriding default_target_compile in > gdb/testsuite/lib/future.exp. Comments indicate that that file was > intended to temporarily bundle certain features with the GDB testsuite > that had not yet been merged into upstream DejaGnu -- in 2004. Now > DejaGnu core is continuing to develop, leaving the old code copied into > the GDB testsuite broken, and making this NOTOURBUG. Well, as the name suggests (regrettably there's no adequate documentation there) this procedure is there to be overridden. The way it's done in GDB might perhaps be non-standard, as the standard way AFAICS would be by providing a `gdb_compile' handler, but I think this is tangential, and the chosen solution is there possibly because DejaGnu had no `${tool}_compile' knob back then (I haven't checked). That does not really matter though, as the net effect would be the same. > In short, this is not a regression in DejaGnu; this is code duplicated > into the GDB testsuite that was slated for removal from that location > years ago and needs to be removed from the GDB testsuite, or at least > made conditional on running under a version of DejaGnu old enough to > require it, if such versions are still supported for running the GDB > testsuite. If that code has added features not present in upstream > DejaGnu over the years, now is the time to get those patches in. Well, it clearly is a functional regression as the interface has changed, even if not a formal one, and I would consider it a release stopper. As it happens there are about 2 users of DejaGnu there, which means any fatal regression would have been easily caught in the course of change verification (and running binutils/GDB and GCC test suites natively is about as easy as it can be: `configure && make && make check'), and indeed should have, and then sorted with the respective communities if indeed the interface change is unavoidable, with a transition period so that the users can prepare changes to their frameworks, including backports to various release branches if applicable, before the old interface is removed from DejaGnu. My suggestion would be to revert the change, get the details sorted with GDB people and only reapply it when all parties are ready. Anyway, I have completed the verification I have volunteered to do and therefore I'm done with my part. Please sort it between the communities. I have other stuff to do I have committed to. Maciej