From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2377 invoked by alias); 27 Apr 2012 20:17:45 -0000 Received: (qmail 2368 invoked by uid 22791); 27 Apr 2012 20:17:43 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Apr 2012 20:17:28 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SNrba-0001u0-QJ from Maciej_Rozycki@mentor.com ; Fri, 27 Apr 2012 13:17:26 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Apr 2012 13:17:26 -0700 Received: from [172.30.0.84] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Fri, 27 Apr 2012 21:17:24 +0100 Date: Fri, 27 Apr 2012 20:23:00 -0000 From: "Maciej W. Rozycki" To: Tom Tromey CC: Pedro Alves , Daniel Jacobowitz , , Richard Sandiford Subject: Re: gdb_test_multiple and empty $message In-Reply-To: <87y5pi8tnm.fsf@fleche.redhat.com> Message-ID: References: <4F916F9E.6040209@redhat.com> <4F99491E.8050605@redhat.com> <87y5pi8tnm.fsf@fleche.redhat.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg01035.txt.bz2 On Thu, 26 Apr 2012, Tom Tromey wrote: > Pedro> My impression gdb_test without a message string is used at places > Pedro> we're sending some commands that just prepare the real test. > Pedro> It's a bit arguable whether we should do that, but there you go. > Pedro> But I think that hiding an internal fail in such preparation > Pedro> steps, which are never ever expected to fail (otherwise you'd > Pedro> pass down a message string to begin with) would be actively > Pedro> harmful, and make it harder to grok and debug testsuite results. > > Yeah, I agree. > > I remember thinking sometimes that it would be nice to have something > like gdb_test_multiple that just returns a status instead of also > logging a pass/fail as a side effect. I can't remember my scenario now. Actually I thought it could be useful for my mips16-thunks.exp test, but there is some uncertainty about what should be considered an internal error for this purpose. As you can see the test already makes use of the return code from gdb_test_multiple; the test could be extended to tell internal errors apart from other failures in the preparatory steps where it wants to ignore most responses that would normally score as failures. And: ".*A problem internal to GDB has been detected" is undoubtedly a bug in GDB the test would rather not ignore (but it does now), as is the EOF condition, but: "Ending remote debugging.*$gdb_prompt $" may or may not be -- if it's `gdbserver' being used, then it's our bug, if it's some other stub, then it may be they just do not support MIPS16 debugging. So for this to work for my case I think gdb_test_multiple would have to define a list of distinct return codes covering individual cases of suspected internal errors (these could be short strings rather than numbers for easier handling, it's TCL not C after all) alongside the message gdb_test_multiple would print should the caller have not requested it to stay silent. And then the caller could decide on a case-by-case basis if to output this message or to ignore the potential failure. Currently the test overrides most of gdb_test_multiple's predefined patterns by supplying "$gdb_prompt $" (and caller's code is prepended so takes precedence). That may be good enough though as it won't let an EOF or "problem internal to GDB" slip through. > Pedro> So I suggest just removing the dead empty string tests from > Pedro> gdb_test_multiple, making the non-empty paths unconditional. > > Yes please. Erm, they're not dead as I noted, merely inconsistent as only applied selectively to some cases, as calling gdb_test_multiple with empty command and message both at a time is valid and perhaps useful sometimes. That's not an objection of any kind though, just an observation for the avoidance of doubt. Maciej