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