Re: gdb_test_multiple and empty $message

["Maciej W. Rozycki" <macro@codesourcery.com>]

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