From: Pedro Alves <palves@redhat.com>
To: Tim Wiederhake <tim.wiederhake@intel.com>, gdb-patches@sourceware.org
Cc: markus.t.metzger@intel.com
Subject: Re: [PATCH v2 1/1] btrace: Resume recording after disconnect.
Date: Thu, 21 Jul 2016 16:17:00 -0000 [thread overview]
Message-ID: <d98ca4f8-ada5-940b-a26a-da8d3141739e@redhat.com> (raw)
In-Reply-To: <1468914307-31108-2-git-send-email-tim.wiederhake@intel.com>
Hi Tim,
Thanks for the update.
On 07/19/2016 08:45 AM, Tim Wiederhake wrote:
> diff --git a/gdb/testsuite/gdb.btrace/reconnect.exp b/gdb/testsuite/gdb.btrace/reconnect.exp
> new file mode 100644
> index 0000000..266ecb4
> --- /dev/null
> +++ b/gdb/testsuite/gdb.btrace/reconnect.exp
> @@ -0,0 +1,73 @@
> +# This testcase is part of GDB, the GNU debugger.
> +#
> +# Copyright 2016 Free Software Foundation, Inc.
> +#
> +# Contributed by Intel Corp. <tim.wiederhake@intel.com>
> +#
> +# 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 gdbserver-support.exp
> +
> +if { [skip_btrace_tests] } { return -1 }
> +if { [skip_gdbserver_tests] } { return -1 }
> +
> +standard_testfile
> +if [prepare_for_testing $testfile.exp $testfile $srcfile] {
> + return -1
> +}
> +
> +# Make sure we're disconnected and no recording is active, in case
> +# we're testing with an extended-remote board, therefore already
> +# connected.
> +gdb_test "record stop" ".*" "preparation record stop"
> +gdb_test "disconnect" ".*" "preparation disconnect"
> +
> +# Start fresh gdbserver.
> +set gdbserver_reconnect_p 1
> +set res [gdbserver_start "" $binfile]
> +set gdbserver_protocol [lindex $res 0]
> +set gdbserver_gdbport [lindex $res 1]
> +gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
> +
> +# Create a record.
> +gdb_test_no_output "record btrace" "record btrace enable" "first record btrace"
> +gdb_test "stepi 19" "0x.* in .* from target.*" "stepi"
> +gdb_test "info record" [multi_line \
> + "Active record target: .*" \
> + "Recorded 19 instructions in .+ functions \\(. gaps\\) for thread 1 \\(Thread .*\\)."
> +] "first info record"
> +
> +# Reconnect.
> +gdb_test "disconnect" "Ending remote debugging." "first reconnect"
> +gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
> +
> +# Test if we can access the recorded data from first connect.
> +# Note: BTS loses the first function call entry with its associated
> +# instructions for technical reasons. This is why we test for
> +# "a number between 10 and 19", so we catch at least the case where
> +# there are 0 instructions in the record.
> +gdb_test "info record" [multi_line \
> + "Active record target: .*" \
> + "Recorded 1. instructions in .+ functions \\(. gaps\\) for thread 1 \\(Thread .*\\)."
> +] "second info record"
> +
> +# Stop recording.
> +gdb_test "record stop" "Process record is stopped and all execution logs are deleted."
> +
> +# Reconnect.
> +gdb_test "disconnect" "Ending remote debugging." "second reconnect"
> +gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
> +
> +# Test that recording is now off.
> +gdb_test "info record" "No record target is currently active." "third info record"
>
Looks mostly good to me, but I'd like to point out something about
test grouping.
A better way to group the separate tests of the testcase is not
to put explicit "second", "third", etc. in the test messages but
to use with_test_prefix. Something like:
with_test_prefix "tracing" {
// disconnect, reconnect, info record
}
with_test_prefix "not tracing" {
// record stop, disconnect, reconnect, info record
}
In many cases, this avoids writing an explicit test message
even (third argument of gdb_test), and has one other more important
advantage -- it makes sure that test messages that are emitted deep
within common procedures like gdb_target_cmd (should it fail) end up
with a unique prefix as well.
Otherwise, LGTM. Markus should have the last word, though.
Thanks,
Pedro Alves
prev parent reply other threads:[~2016-07-21 16:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 7:45 [PATCH v2 0/1] " Tim Wiederhake
2016-07-19 7:45 ` [PATCH v2 1/1] " Tim Wiederhake
2016-07-21 16:17 ` 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=d98ca4f8-ada5-940b-a26a-da8d3141739e@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@intel.com \
--cc=tim.wiederhake@intel.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