Message ID | 1434770234-24916-1-git-send-email-vapier@gentoo.org |
---|---|
State | New, archived |
Delegated to: | Mike Frysinger |
Headers |
Received: (qmail 37755 invoked by alias); 20 Jun 2015 03:17:24 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 37711 invoked by uid 89); 20 Jun 2015 03:17:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 20 Jun 2015 03:17:17 +0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 1EA95340C1C for <gdb-patches@sourceware.org>; Sat, 20 Jun 2015 03:17:16 +0000 (UTC) From: Mike Frysinger <vapier@gentoo.org> To: gdb-patches@sourceware.org Subject: [PATCH] gdb: tests: mark async unsupported dynamically Date: Fri, 19 Jun 2015 23:17:14 -0400 Message-Id: <1434770234-24916-1-git-send-email-vapier@gentoo.org> X-IsSubscribed: yes |
Commit Message
Mike Frysinger
June 20, 2015, 3:17 a.m. UTC
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(+)
Comments
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
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
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
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" }