gdb_test_multiple and empty $message

[Pedro Alves <palves@redhat.com>]

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