2014-01-01 03:54:24 +00:00
# Copyright 2011-2014 Free Software Foundation, Inc.
2011-11-20 23:59:49 +00:00
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
load_lib "trace-support.exp"
2012-06-26 18:25:19 +00:00
standard_testfile actions.c
2011-11-20 23:59:49 +00:00
set executable $testfile
set expfile tstatus.exp
if [prepare_for_testing $expfile $executable $srcfile \
[list debug]] {
untested "failed to prepare for trace tests"
return -1
}
if ![runto_main] {
fail "Can't run to main to check for trace support"
return -1
}
if ![gdb_target_supports_trace] {
unsupported "target does not support trace"
return -1
}
2013-03-14 09:12:21 +00:00
set tstatus_output ""
2011-11-20 23:59:49 +00:00
proc run_trace_experiment {} {
2011-12-02 12:43:29 +00:00
global gdb_prompt
2013-01-18 06:40:58 +00:00
global decimal
2013-03-14 09:12:21 +00:00
global tstatus_output
2011-11-20 23:59:49 +00:00
# gdb_test_no_output "set debug remote 1" ""
gdb_test "continue" \
".*Breakpoint \[0-9\]+, begin .*" \
"advance to trace begin"
gdb_test_no_output "tstart my tracing note" "start trace experiment"
gdb_test "continue" \
".*Breakpoint \[0-9\]+, end .*" \
"advance through tracing"
# Now play with tstatus a bit.
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.
2013-03-06 12:13:41 +00:00
# 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 {
2011-12-02 12:43:29 +00:00
-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 $" {
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.
2013-03-06 12:13:41 +00:00
pass $test
2011-11-20 23:59:49 +00:00
}
2011-12-02 12:43:29 +00:00
-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Not looking at any trace frame.*\r\n$gdb_prompt $" {
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.
2013-03-06 12:13:41 +00:00
unsupported $test
2011-11-20 23:59:49 +00:00
}
}
gdb_test "set trace-notes different note" "" "change tracing note"
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.
2013-03-06 12:13:41 +00:00
set test "tstatus reports different trace note"
gdb_test_multiple "tstatus" $test {
2011-12-02 12:43:29 +00:00
-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 $" {
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.
2013-03-06 12:13:41 +00:00
pass $test
2011-11-20 23:59:49 +00:00
}
2011-12-02 12:43:29 +00:00
-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Not looking at any trace frame.*\r\n$gdb_prompt $" {
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.
2013-03-06 12:13:41 +00:00
unsupported $test
2011-11-20 23:59:49 +00:00
}
}
gdb_test "set trace-user me me me" "" "change tracing user"
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.
2013-03-06 12:13:41 +00:00
set test "tstatus reports trace user"
gdb_test_multiple "tstatus" $test {
2011-12-02 12:43:29 +00:00
-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 $" {
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.
2013-03-06 12:13:41 +00:00
pass $test
2011-11-20 23:59:49 +00:00
}
2011-12-02 12:43:29 +00:00
-re "Trace is running.*Trace will stop if GDB disconnects\.\[\r\n\]+Not looking at any trace frame.*\r\n$gdb_prompt $" {
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.
2013-03-06 12:13:41 +00:00
unsupported $test
2011-11-20 23:59:49 +00:00
}
}
gdb_test_no_output "tstop because I can" "trace stopped with note"
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.
2013-03-06 12:13:41 +00:00
set test "tstatus reports trace stop reason"
gdb_test_multiple "tstatus" $test {
2013-03-14 09:12:21 +00:00
-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 $" {
set tstatus_output $expect_out(1,string)
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.
2013-03-06 12:13:41 +00:00
pass $test
2011-11-20 23:59:49 +00:00
}
2013-03-14 09:12:21 +00:00
-re "(Trace stopped by a tstop command\.).*\r\n$gdb_prompt $" {
set tstatus_output $expect_out(1,string)
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.
2013-03-06 12:13:41 +00:00
unsupported $test
2011-11-20 23:59:49 +00:00
}
}
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.
2013-03-06 12:13:41 +00:00
set test "info trace reports tracepoint hit count and traceframe usage"
gdb_test_multiple "info trace" $test {
2013-01-18 06:40:58 +00:00
-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 $" {
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.
2013-03-06 12:13:41 +00:00
pass $test
2011-11-20 23:59:49 +00:00
}
2011-12-02 12:43:29 +00:00
-re "actions\.c:\[0-9\]+\[\r\n\]+\[\t ]+collect parm.*\r\n$gdb_prompt $" {
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.
2013-03-06 12:13:41 +00:00
unsupported $test
2011-11-20 23:59:49 +00:00
}
}
}
proc test_tracepoints {} {
2011-12-02 12:43:29 +00:00
global gdb_prompt
2011-11-20 23:59:49 +00:00
gdb_test "break begin" ".*" ""
gdb_test "break end" ".*" ""
gdb_test "trace gdb_c_test" "Tracepoint .*" \
"tracepoint at gdb_c_test"
gdb_trace_setactions "collect at set_point: define actions" \
"" \
"collect parm" "^$"
run_trace_experiment
}
test_tracepoints
2013-03-14 09:12:21 +00:00
set tracefile [standard_output_file ${testfile}]
# Save trace frames to tfile.
gdb_test "tsave ${tracefile}.tf" \
"Trace data saved to file '${tracefile}.tf'.*" \
"save tfile trace file"
gdb/
2013-04-10 Hui Zhu <hui@codesourcery.com>
Yao Qi <yao@codesourcery.com>
* configure.ac: Check libbabeltrace is installed.
* config.in: Regenerate.
* configure: Regenerate.
* Makefile.in (LIBBABELTRACE): New.
(CLIBS): Add LIBBABELTRACE.
* ctf.c: Include "exec.h".
(CTF_EVENT_ID_STATUS, CTF_EVENT_ID_TSV_DEF): New macros.
(CTF_EVENT_ID_TP_DEF, ctf_save_write_int32): New macros.
(ctf_save_metadata_header): Define new type aliases in
metadata.
(ctf_write_header): Define event type "tsv_def" and "tp_def"
in metadata. Start a new faked packet for trace status.
(ctf_write_status): Write trace status to CTF.
(ctf_write_uploaded_tsv): Write TSV to CTF.
(ctf_write_uploaded_tp): Write tracepoint definition to CTF.
(ctf_write_definition_end): End the faked packet.
(ctx, ctf_iter, trace_dirname): New.
(start_pos): New variable.
(ctf_destroy, ctf_open_dir, ctf_open): New.
(SET_INT32_FIELD, SET_ARRAY_FIELD, SET_STRING_FIELD): New
macros.
(ctf_read_tsv, ctf_read_tp, ctf_close, ctf_files_info): New.
(ctf_fetch_registers, ctf_xfer_partial): New.
(ctf_get_trace_state_variable_value): New.
(ctf_get_tpnum_from_frame_event): New.
(ctf_get_traceframe_address): New.
(ctf_trace_find, ctf_has_stack): New.
(ctf_has_registers, ctf_traceframe_info, init_ctf_ops): New.
(ctf_get_trace_status, ctf_read_status): New.
(_initialize_ctf): New.
* tracepoint.c (get_tracepoint_number): New
(get_uploaded_tsv): Remove 'static'.
(struct traceframe_info, trace_regblock_size): Move it to ...
* tracepoint.h: ... here.
(get_tracepoint_number): Declare it.
(get_uploaded_tsv): Declare it.
* NEWS: Mention new configure option.
gdb/doc/
2013-04-10 Yao Qi <yao@codesourcery.com>
* gdb.texinfo (Trace Files): Add "target ctf".
gdb/testsuite/
2013-04-10 Yao Qi <yao@codesourcery.com>
* gdb.trace/actions.exp: Save trace data to CTF.
Change to ctf target if GDB supports, read CTF data in ctf
target, and check the actions of tracepoints.
* gdb.trace/while-stepping.exp: Likewise.
* gdb.trace/report.exp: Test GDB saves trace data to CTF
format and read CTF trace file if GDB supports.
* gdb.trace/tstatus.exp: Save trace data to CTF. If ctf
target is supported, change to ctf target, read trace data and
check output of command "tstatus".
* gdb.trace/tsv.exp: Save trace frame to CTF. If GDB supports,
read CTF data by target ctf and call check_tsv.
2013-04-10 09:42:57 +00:00
# Save trace frames to CTF.
gdb_test "tsave -ctf ${tracefile}.ctf" \
"Trace data saved to directory '${tracefile}.ctf'.*" \
"save ctf trace file"
2013-03-14 09:12:21 +00:00
# Change target to tfile.
set test "change to tfile target"
gdb_test_multiple "target tfile ${tracefile}.tf" "$test" {
-re "A program is being debugged already. Kill it. .y or n. " {
send_gdb "y\n"
exp_continue
}
-re "$gdb_prompt $" {
pass "$test"
}
}
# Convert "(because I can) to "\(because I can\)"
set tstatus_output [string map {\( \\(} $tstatus_output]
set tstatus_output [string map {\) \\)} $tstatus_output]
# The status should be identical to the status of live inferior.
gdb_test "tstatus" "Using a trace file\.\r\n${tstatus_output}.*" \
"tstatus on tfile target"
gdb/
2013-04-10 Hui Zhu <hui@codesourcery.com>
Yao Qi <yao@codesourcery.com>
* configure.ac: Check libbabeltrace is installed.
* config.in: Regenerate.
* configure: Regenerate.
* Makefile.in (LIBBABELTRACE): New.
(CLIBS): Add LIBBABELTRACE.
* ctf.c: Include "exec.h".
(CTF_EVENT_ID_STATUS, CTF_EVENT_ID_TSV_DEF): New macros.
(CTF_EVENT_ID_TP_DEF, ctf_save_write_int32): New macros.
(ctf_save_metadata_header): Define new type aliases in
metadata.
(ctf_write_header): Define event type "tsv_def" and "tp_def"
in metadata. Start a new faked packet for trace status.
(ctf_write_status): Write trace status to CTF.
(ctf_write_uploaded_tsv): Write TSV to CTF.
(ctf_write_uploaded_tp): Write tracepoint definition to CTF.
(ctf_write_definition_end): End the faked packet.
(ctx, ctf_iter, trace_dirname): New.
(start_pos): New variable.
(ctf_destroy, ctf_open_dir, ctf_open): New.
(SET_INT32_FIELD, SET_ARRAY_FIELD, SET_STRING_FIELD): New
macros.
(ctf_read_tsv, ctf_read_tp, ctf_close, ctf_files_info): New.
(ctf_fetch_registers, ctf_xfer_partial): New.
(ctf_get_trace_state_variable_value): New.
(ctf_get_tpnum_from_frame_event): New.
(ctf_get_traceframe_address): New.
(ctf_trace_find, ctf_has_stack): New.
(ctf_has_registers, ctf_traceframe_info, init_ctf_ops): New.
(ctf_get_trace_status, ctf_read_status): New.
(_initialize_ctf): New.
* tracepoint.c (get_tracepoint_number): New
(get_uploaded_tsv): Remove 'static'.
(struct traceframe_info, trace_regblock_size): Move it to ...
* tracepoint.h: ... here.
(get_tracepoint_number): Declare it.
(get_uploaded_tsv): Declare it.
* NEWS: Mention new configure option.
gdb/doc/
2013-04-10 Yao Qi <yao@codesourcery.com>
* gdb.texinfo (Trace Files): Add "target ctf".
gdb/testsuite/
2013-04-10 Yao Qi <yao@codesourcery.com>
* gdb.trace/actions.exp: Save trace data to CTF.
Change to ctf target if GDB supports, read CTF data in ctf
target, and check the actions of tracepoints.
* gdb.trace/while-stepping.exp: Likewise.
* gdb.trace/report.exp: Test GDB saves trace data to CTF
format and read CTF trace file if GDB supports.
* gdb.trace/tstatus.exp: Save trace data to CTF. If ctf
target is supported, change to ctf target, read trace data and
check output of command "tstatus".
* gdb.trace/tsv.exp: Save trace frame to CTF. If GDB supports,
read CTF data by target ctf and call check_tsv.
2013-04-10 09:42:57 +00:00
# Change target to ctf if GDB supports.
gdb_test_multiple "target ctf ${tracefile}.ctf" "" {
-re "Undefined target command: \"ctf ${tracefile}.ctf\"\. Try \"help target\"\.\r\n$gdb_prompt $" {
}
-re ".*\r\n$gdb_prompt $" {
gdb_test "tstatus" "Using a trace file\.\r\n${tstatus_output}.*" \
"tstatus on ctf target"
}
}