This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
gdb_test_multiple and empty $message
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