[PATCH] gdb: tests: mark async unsupported dynamically

[PATCH] gdb: tests: mark async unsupported dynamically

[Mike Frysinger]

There are many targets which do not support asynchronous execution.
Rather than having the async tests mark them as FAIL, use UNSUPPORTED
as that better represents the state.
---
2015-06-19  Mike Frysinger  <vapier@gentoo.org>

	* gdb.base/async.exp (test_background): Call unsupported when async
	isn't supported.

 gdb/testsuite/gdb.base/async.exp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gdb/testsuite/gdb.base/async.exp b/gdb/testsuite/gdb.base/async.exp
index 2d3fb73..4b9168a 100644
--- a/gdb/testsuite/gdb.base/async.exp
+++ b/gdb/testsuite/gdb.base/async.exp
@@ -58,6 +58,9 @@ proc test_background {command before_prompt after_prompt {message ""}} {
 	-re "^$command\r\n${before_prompt}${gdb_prompt}${after_prompt}completed\.\r\n" {
 	    pass "$message"
 	}
+	-re "Asynchronous execution not supported on this target\.\r\n" {
+	    unsupported "$message"
+	}
 	-re "$gdb_prompt.*completed\.\r\n" {
 	    fail "$message"
 	}
-- 
2.2.0.rc0.207.ga3a616c

Re: [PATCH] gdb: tests: mark async unsupported dynamically

[Pedro Alves]

On 06/20/2015 04:17 AM, Mike Frysinger wrote:
> There are many targets which do not support asynchronous execution.
> Rather than having the async tests mark them as FAIL, use UNSUPPORTED
> as that better represents the state.
> ---
> 2015-06-19  Mike Frysinger  <vapier@gentoo.org>
> 
> 	* gdb.base/async.exp (test_background): Call unsupported when async
> 	isn't supported.
> 
>  gdb/testsuite/gdb.base/async.exp | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.base/async.exp b/gdb/testsuite/gdb.base/async.exp
> index 2d3fb73..4b9168a 100644
> --- a/gdb/testsuite/gdb.base/async.exp
> +++ b/gdb/testsuite/gdb.base/async.exp
> @@ -58,6 +58,9 @@ proc test_background {command before_prompt after_prompt {message ""}} {
>  	-re "^$command\r\n${before_prompt}${gdb_prompt}${after_prompt}completed\.\r\n" {
>  	    pass "$message"
>  	}
> +	-re "Asynchronous execution not supported on this target\.\r\n" {
> +	    unsupported "$message"
> +	}
>  	-re "$gdb_prompt.*completed\.\r\n" {
>  	    fail "$message"
>  	}
> 

We should also return something that the caller checks to bail the
rest of the file.  Otherwise, as soon as we add something to the
test that expects that e.g., "print foo" returns some value after the
previous async commands worked, that test will fail on sync targets.

Something like:

    send_gdb "$command\n"
    gdb_expect {
	-re "^$command\r\n${before_prompt}${gdb_prompt}${after_prompt}completed\.\r\n" {
	    pass "$message"
+           return 0
	}
	-re "$gdb_prompt.*completed\.\r\n" {
	    fail "$message"
	}
	timeout  {
	    fail "$message (timeout)"
	}
    }

+   return -1
}

and:

-test_background "next&" "" ".*z = 9.*"
+if {[test_background "next&" "" ".*z = 9.*"] < 0} {
+  return
+}

... rest unchanged ...

Thanks,
Pedro Alves

Re: [PATCH] gdb: tests: mark async unsupported dynamically

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]

On 24 Jun 2015 12:25, Pedro Alves wrote:
> On 06/20/2015 04:17 AM, Mike Frysinger wrote:
> > There are many targets which do not support asynchronous execution.
> > Rather than having the async tests mark them as FAIL, use UNSUPPORTED
> > as that better represents the state.
> > ---
> > 2015-06-19  Mike Frysinger  <vapier@gentoo.org>
> > 
> > 	* gdb.base/async.exp (test_background): Call unsupported when async
> > 	isn't supported.
> > 
> >  gdb/testsuite/gdb.base/async.exp | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/gdb/testsuite/gdb.base/async.exp b/gdb/testsuite/gdb.base/async.exp
> > index 2d3fb73..4b9168a 100644
> > --- a/gdb/testsuite/gdb.base/async.exp
> > +++ b/gdb/testsuite/gdb.base/async.exp
> > @@ -58,6 +58,9 @@ proc test_background {command before_prompt after_prompt {message ""}} {
> >  	-re "^$command\r\n${before_prompt}${gdb_prompt}${after_prompt}completed\.\r\n" {
> >  	    pass "$message"
> >  	}
> > +	-re "Asynchronous execution not supported on this target\.\r\n" {
> > +	    unsupported "$message"
> > +	}
> >  	-re "$gdb_prompt.*completed\.\r\n" {
> >  	    fail "$message"
> >  	}
> > 
> 
> We should also return something that the caller checks to bail the
> rest of the file.  Otherwise, as soon as we add something to the
> test that expects that e.g., "print foo" returns some value after the
> previous async commands worked, that test will fail on sync targets.

returning an error on unsupported makes sense.  but if we fail in general, don't 
want to run all tests and such still ?
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] gdb: tests: mark async unsupported dynamically

[Pedro Alves]

On 06/25/2015 12:21 PM, Mike Frysinger wrote:
> On 24 Jun 2015 12:25, Pedro Alves wrote:
>> We should also return something that the caller checks to bail the
>> rest of the file.  Otherwise, as soon as we add something to the
>> test that expects that e.g., "print foo" returns some value after the
>> previous async commands worked, that test will fail on sync targets.
> 
> returning an error on unsupported makes sense.  but if we fail in general, don't 
> want to run all tests and such still ?

In general I agree we should consider that.  E.g.,
gdb.base/interrupt-noterm.exp skips the rest of the tests only if async
isn't supported, not on failure.  But that one open codes the async-supported check.
Here, it didn't seem worth the trouble to have separate record codes, though I'm
certainly fine with it.  (E.g., -1/0/1.)  The reason it didn't feel like
worth the trouble is that if you fail the first "next&", then the rest of
the tests will no longer make sense anyway, as they will depend on
having nexted correctly to the right line.  So the very likely result is
a cascade of FAIL timeouts.  Hence a single FAIL seems good enough.
But as said, if you want to add the distinction, super fine with me.  Might
be a good idea if we move the test_background to lib/gdb.exp and use it in
other tests (like gdb.base/interrupt-noterm.exp) anyway.

Thanks,
Pedro Alves