From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21676 invoked by alias); 26 Apr 2012 13:10:24 -0000 Received: (qmail 21538 invoked by uid 22791); 26 Apr 2012 13:10:23 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Apr 2012 13:09:57 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3QD9qXg032619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Apr 2012 09:09:52 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3QD9o2D031683; Thu, 26 Apr 2012 09:09:51 -0400 Message-ID: <4F99491E.8050605@redhat.com> Date: Thu, 26 Apr 2012 13:23:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Daniel Jacobowitz , gdb-patches@sourceware.org, Richard Sandiford Subject: gdb_test_multiple and empty $message References: <4F916F9E.6040209@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00901.txt.bz2 On 04/25/2012 11:01 PM, Maciej W. Rozycki wrote: > Out of curiosity gdb_test_multiple contains this: > > if { $message == "" } { > set message $command > } > > at the very beginning, and then lots of pieces like this: > > -re "\\*\\*\\* DOSEXIT code.*" { > if { $message != "" } { > fail "$message"; > } > gdb_suppress_entire_file "GDB died"; > set result -1; > } > > (this has weird indentation too, more cases elsewhere), or this: > > if ![string match "" $message] then { > set errmsg "$message (the program exited)" > } else { > set errmsg "$command (the program exited)" > } > > or this: > > timeout { > if ![string match "" $message] then { > fail "$message (timeout)" > } > set result 1 > } > > Are these meant to trigger where both the command and the message supplied > are empty? Or are they just a leftover from past time? Looking at the history, gdb_test_multiple was introduced as a split out of gdb_test. And it seems gdb_test already supported hidding a PASS by passing down no message string even before gdb_test_multiple's introduction. But this comment: # MESSAGE is an optional message to be printed. If this is # omitted, then the pass/fail messages use the command string as the # message. (If this is the empty string, then sometimes we don't # call pass or fail at all; I don't understand this at all.) already existed back then. > Shouldn't the conditions be made consistent throughout, i.e. no fail invocation where > $message is ultimately still empty? Or just removed? My impression gdb_test without a message string is used at places we're sending some commands that just prepare the real test. It's a bit arguable whether we should do that, but there you go. But I think that hiding an internal fail in such preparation steps, which are never ever expected to fail (otherwise you'd pass down a message string to begin with) would be actively harmful, and make it harder to grok and debug testsuite results. For gdb_test_multiple itself, which never issues a "pass" itself, I think the empty-message-means-command-string-is-the-message is really what people that call it directly always expect, and likewise hiding an internal fail for gdb_test_multiple direct call would be actively harmful, IMO. So I suggest just removing the dead empty string tests from gdb_test_multiple, making the non-empty paths unconditional. -- Pedro Alves