Re: How to abort a test?

[Simon Marchi <simon.marchi@ericsson.com>]

On 16-01-17 03:27 AM, Joel Brobecker wrote:
> I admit that some of it flying a little over my head... Does it
> mean that we will be able to abort a test if we detect a timeout?
> This is one of the things I wanted to do, but didn't have a solution
> for, so it'd be fantastic if it helped with that!

--status does no really impact how a timeout is handled.  What happens
when a timeout occurs in gdb_test is defined by us.  Right now, it
produces a test "fail":

testsuite/lib/gdb.exp:
  937         timeout {
  938             if ![string match "" $message] then {
  939                 fail "$message (timeout)"
  940             }
  941             set result 1
  942         }

So you see, for example:

  FAIL: gdb.base/break.exp: some test (timeout)

and the test case carries on.  A gdb_test timeout is no different than
a regular fail.  If you replace the "fail" at line 939 with "error",
which throws a TCL exception, then the current test case will abort,
although in this quite ugly way:

  Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.base/break.exp ...
  ERROR OCCURED: some test (timeout)
      while executing
  "error "$message (timeout)""
      invoked from within
  "if ![string match "" $message] then {
  		error "$message (timeout)"
  	    }"
      invoked from within
  "expect {
  -i exp8 -timeout 1
  	-re ".*A problem internal to GDB has been detected" {
  	    fail "$message (GDB internal error)"
  	    gdb_internal_error_..."
      ("uplevel" body line 1)
      invoked from within
  "uplevel $body" NONE insert breakpoint (timeout)WARNING: remote_expect statement without a default case?!

The current test case is stopped and the next .exp is ran.  However,
if you don't use --status on the runtest command line, the uncaught
exception will not be considered as an error.  So if you use
"make check" in a script, you won't notice the failure.