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.

0 files changed, 0 insertions, 0 deletions