Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: tstatus.exp: use UNSUPPORTED for optional features that are not supported
Date: Wed, 06 Mar 2013 12:19:00 -0000	[thread overview]
Message-ID: <5137342A.7040300@redhat.com> (raw)
In-Reply-To: <5136982D.9040108@codesourcery.com>

On 03/06/2013 01:13 AM, Yao Qi wrote:
> Pedro,
> The patch looks pretty good to me.
> 
> On 03/06/2013 03:02 AM, Pedro Alves wrote:
>> +    set test "tstatus reports trace note"
>>       gdb_test_multiple "tstatus" "check on trace status" {
>                                     ^^^^^^^^^^^^^^^^^^^^^^ use $test here.

Thanks.

Here's what I checked in.

-- >8 --
Subject: tstatus.exp: use UNSUPPORTED for optional features that are not supported

The current tstatus.exp tests shows PASSes if either the target
support or not the optional tstatus bits:

 PASS: gdb.trace/tstatus.exp: tstatus does not report trace stop reason
 PASS: gdb.trace/tstatus.exp: tstatus reports trace stop reason

The former (and any other similar case) should be UNSUPPORTED rather
than PASS.  That'd make it much easier to spot actually problems with
the test (e.g., the one Yao's previous patch addressed), along with
regressions and progressions.

The "not supported" paths in tstatus.exp explicitly check for output
you'd get if the feature wasn't supported, so real unexpected failures
will still be caught as FAILs.

So now e.g., where we wanted to check if tstatus reports the trace
stop reason, and if the target does support it, we get

 PASS: tstatus reports trace stop reason

if the target actually reports what we'd expect if the trace stop
reason isn't supported, we get:

 UNSUPPORTED: tstatus reports trace stop reason

and if the target reports something else unexpected, we get:

 FAIL: tstatus reports trace stop reason

That has the added bonus that the test string is always the same and
only the test results change (PASS/FAIL/UNSUPPORTED), which makes it
easier for testers see regressions, compared to the previous:

 -PASS: gdb.trace/tstatus.exp: tstatus reports trace stop reason
 +PASS: gdb.trace/tstatus.exp: tstatus does not report trace stop reason

which clearly easily goes by unnoticed, as evidenced by the existing
problem Yao's previous patch addressed.

Tested on x86_64 Fedora 17.

gdb/testsuite/
2013-03-06  Pedro Alves  <palves@redhat.com>

	* gdb.trace/tstatus.exp (run_trace_experiment): When the target
	doesn't support the tested optional feature, call "unsupported"
	with the same test message as the "pass" case, instead of calling
	"pass" with a different message.  Use the same text for the "fail"
	cases too.
---
 gdb/testsuite/gdb.trace/tstatus.exp |   43 +++++++++++++++++++----------------
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/gdb/testsuite/gdb.trace/tstatus.exp b/gdb/testsuite/gdb.trace/tstatus.exp
index 46faaf8..743db91 100644
--- a/gdb/testsuite/gdb.trace/tstatus.exp
+++ b/gdb/testsuite/gdb.trace/tstatus.exp
@@ -51,60 +51,63 @@ proc run_trace_experiment {} {
 	"advance through tracing"
      # Now play with tstatus a bit.
-    # Since note support is optional, we need to match both with and without
-    # cases.
 -    gdb_test_multiple "tstatus" "check on trace status" {
+    # Since support for notes, user, stop reason, etc. is optional, we
+    # need to match both with and without cases.
+
+    set test "tstatus reports trace note"
+    gdb_test_multiple "tstatus" $test {
 	-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Trace notes: my tracing note\.\[\r\n\]+Not looking at any trace frame\..*\r\n$gdb_prompt $" {
-	    pass "tstatus reports trace note"
+	    pass $test
 	}
 	-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Not looking at any trace frame.*\r\n$gdb_prompt $" {
-	    pass "tstatus does not report any trace note"
+	    unsupported $test
 	}
     }
      gdb_test "set trace-notes different note" "" "change tracing note"
 -    gdb_test_multiple "tstatus" "check on trace status with diff note" {
+    set test "tstatus reports different trace note"
+    gdb_test_multiple "tstatus" $test {
 	-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Trace notes: different note\.\[\r\n\]+Not looking at any trace frame\..*\r\n$gdb_prompt $" {
-	    pass "tstatus reports different trace note"
+	    pass $test
 	}
 	-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Not looking at any trace frame.*\r\n$gdb_prompt $" {
-	    pass "tstatus does not report any different trace note"
+	    unsupported $test
 	}
     }
      gdb_test "set trace-user me me me" "" "change tracing user"
 -    gdb_test_multiple "tstatus" "check on trace status with diff note" {
+    set test "tstatus reports trace user"
+    gdb_test_multiple "tstatus" $test {
 	-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Trace user is me me me\.\[\r\n\]+Trace notes: different note\.\[\r\n\]+Not looking at any trace frame\..*\r\n$gdb_prompt $" {
-	    pass "tstatus reports trace user"
+	    pass $test
 	}
 	-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Not looking at any trace frame.*\r\n$gdb_prompt $" {
-	    pass "tstatus does not report trace user"
+	    unsupported $test
 	}
     }
      gdb_test_no_output "tstop because I can" "trace stopped with note"
 -    gdb_test_multiple "tstatus" "check on trace status after stop" {
+    set test "tstatus reports trace stop reason"
+    gdb_test_multiple "tstatus" $test {
 	-re "Trace stopped by a tstop command \\(because I can\\)\..*Trace will stop if GDB disconnects\.\[\r\n\]+Trace user is me me me\.\[\r\n\]+Trace notes: different note\.\[\r\n\]+Not looking at any trace frame\..*\r\n$gdb_prompt $" {
-	    pass "tstatus reports trace stop reason"
+	    pass $test
 	}
 	-re "Trace stopped by a tstop command\..*\r\n$gdb_prompt $" {
-	    pass "tstatus does not report trace stop reason"
+	    unsupported $test
 	}
     }
 -    # Hit count and traceframe usage of tracepoint is optional, so
-    # pass it either way.
-
-    gdb_test_multiple "info trace" "show tracepoint state" {
+    set test "info trace reports tracepoint hit count and traceframe usage"
+    gdb_test_multiple "info trace" $test {
 	-re "actions\.c:\[0-9\]+\[\r\n\]+\[\t ]+tracepoint already hit 1 time\[\r\n\]+\[\t ]+trace buffer usage ${decimal} bytes\.\[\r\n\]+\[\t ]+collect parm.*\r\n$gdb_prompt $" {
-	    pass "info trace reports tracepoint hit count and traceframe usage"
+	    pass $test
 	}
 	-re "actions\.c:\[0-9\]+\[\r\n\]+\[\t ]+collect parm.*\r\n$gdb_prompt $" {
-	    pass "info trace does not report tracepoint hit count and traceframe usage"
+	    unsupported $test
 	}
     }
 }


      reply	other threads:[~2013-03-06 12:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-04 15:37 [PATCH] Fix a bug in tstatus.exp matching tstatus output Yao Qi
2013-03-04 16:23 ` Joel Brobecker
2013-03-04 17:35   ` Tom Tromey
2013-03-05  2:24   ` Yao Qi
2013-03-05 19:09     ` Pedro Alves
2013-03-04 16:32 ` Pedro Alves
2013-03-05  2:39   ` Yao Qi
2013-03-05 19:02     ` tstatus.exp: use UNSUPPORTED for optional features that are not supported (was: Re: [PATCH] Fix a bug in tstatus.exp matching tstatus output) Pedro Alves
2013-03-06  1:14       ` tstatus.exp: use UNSUPPORTED for optional features that are not supported Yao Qi
2013-03-06 12:19         ` Pedro Alves [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5137342A.7040300@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox