2016-01-01 04:33:14 +00:00
|
|
|
# Copyright 2013-2016 Free Software Foundation, Inc.
|
2013-05-23 17:19:05 +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/>.
|
|
|
|
|
|
|
|
# Execute command CMD and check that GDB sends the expected number of
|
Remove checking vCont;s in exec_cmd_expect_vCont_count
Nowadays, in the range-stepping tests, we check not only the number of
vCont;r packets but also the number of vCont;s packets, because we think
the remote target which can do range stepping must support single step.
However, if we turn displaced stepping on, the remote target (GDBserver)
can do range stepping, and support single step, but GDB may decide to
resume instructions in the scratchpad rather than single step them one
by one for displaced stepping. For example, when aarch64 GDB debugs
arm linux program with aarch64 GDBserver, GDBserver supports both range
stepping and single step, but GDB (with the gdbarch for arm-linux)
decides resume instructions in the scratchpad, so in the RSP traffic,
there is no vCont;s packet at all, and some range-stepping.exp tests
fail,
FAIL: gdb.base/range-stepping.exp: multi insns: next: vCont;s=1 vCont;r=1
This patch is to get rid of the checking to the number of vCont;s in
exec_cmd_expect_vCont_count.
gdb/testsuite:
2015-10-21 Yao Qi <yao.qi@linaro.org>
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Remove argument exp_vCont_s.
* gdb.base/range-stepping.exp: Callers updated.
* gdb.trace/range-stepping.exp: Likewise.
2015-10-21 15:16:25 +00:00
|
|
|
# vCont;r packet. Returns 0 if the test passes, otherwise returns 1.
|
2013-05-23 17:19:05 +00:00
|
|
|
|
Remove checking vCont;s in exec_cmd_expect_vCont_count
Nowadays, in the range-stepping tests, we check not only the number of
vCont;r packets but also the number of vCont;s packets, because we think
the remote target which can do range stepping must support single step.
However, if we turn displaced stepping on, the remote target (GDBserver)
can do range stepping, and support single step, but GDB may decide to
resume instructions in the scratchpad rather than single step them one
by one for displaced stepping. For example, when aarch64 GDB debugs
arm linux program with aarch64 GDBserver, GDBserver supports both range
stepping and single step, but GDB (with the gdbarch for arm-linux)
decides resume instructions in the scratchpad, so in the RSP traffic,
there is no vCont;s packet at all, and some range-stepping.exp tests
fail,
FAIL: gdb.base/range-stepping.exp: multi insns: next: vCont;s=1 vCont;r=1
This patch is to get rid of the checking to the number of vCont;s in
exec_cmd_expect_vCont_count.
gdb/testsuite:
2015-10-21 Yao Qi <yao.qi@linaro.org>
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Remove argument exp_vCont_s.
* gdb.base/range-stepping.exp: Callers updated.
* gdb.trace/range-stepping.exp: Likewise.
2015-10-21 15:16:25 +00:00
|
|
|
proc exec_cmd_expect_vCont_count { cmd exp_vCont_r } {
|
2013-05-23 17:19:05 +00:00
|
|
|
global gdb_prompt
|
|
|
|
|
|
|
|
gdb_test_no_output "set debug remote 1" ""
|
|
|
|
|
Remove checking vCont;s in exec_cmd_expect_vCont_count
Nowadays, in the range-stepping tests, we check not only the number of
vCont;r packets but also the number of vCont;s packets, because we think
the remote target which can do range stepping must support single step.
However, if we turn displaced stepping on, the remote target (GDBserver)
can do range stepping, and support single step, but GDB may decide to
resume instructions in the scratchpad rather than single step them one
by one for displaced stepping. For example, when aarch64 GDB debugs
arm linux program with aarch64 GDBserver, GDBserver supports both range
stepping and single step, but GDB (with the gdbarch for arm-linux)
decides resume instructions in the scratchpad, so in the RSP traffic,
there is no vCont;s packet at all, and some range-stepping.exp tests
fail,
FAIL: gdb.base/range-stepping.exp: multi insns: next: vCont;s=1 vCont;r=1
This patch is to get rid of the checking to the number of vCont;s in
exec_cmd_expect_vCont_count.
gdb/testsuite:
2015-10-21 Yao Qi <yao.qi@linaro.org>
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Remove argument exp_vCont_s.
* gdb.base/range-stepping.exp: Callers updated.
* gdb.trace/range-stepping.exp: Likewise.
2015-10-21 15:16:25 +00:00
|
|
|
set test "${cmd}: vCont;r=${exp_vCont_r}"
|
2013-05-23 17:19:05 +00:00
|
|
|
set r_counter 0
|
|
|
|
set s_counter 0
|
2013-05-24 09:57:12 +00:00
|
|
|
set ret 1
|
2015-11-30 16:05:23 +00:00
|
|
|
# We either get a stop reply in all-stop mode, or an OK in
|
|
|
|
# non-stop mode.
|
|
|
|
set vcont_reply "(T\[\[:xdigit:\]\]\[\[:xdigit:\]\]|OK)"
|
2013-05-23 17:19:05 +00:00
|
|
|
gdb_test_multiple $cmd $test {
|
2015-11-30 16:05:23 +00:00
|
|
|
-re "vCont;s\[^\r\n\]*Packet received: $vcont_reply" {
|
2013-05-23 17:19:05 +00:00
|
|
|
incr s_counter
|
|
|
|
exp_continue
|
|
|
|
}
|
2015-11-30 16:05:23 +00:00
|
|
|
-re "vCont;r\[^\r\n\]*Packet received: $vcont_reply" {
|
2013-05-23 17:19:05 +00:00
|
|
|
incr r_counter
|
|
|
|
exp_continue
|
|
|
|
}
|
|
|
|
-re "\r\n" {
|
|
|
|
# Prevent overflowing the expect buffer.
|
|
|
|
exp_continue
|
|
|
|
}
|
|
|
|
-re "$gdb_prompt $" {
|
Remove checking vCont;s in exec_cmd_expect_vCont_count
Nowadays, in the range-stepping tests, we check not only the number of
vCont;r packets but also the number of vCont;s packets, because we think
the remote target which can do range stepping must support single step.
However, if we turn displaced stepping on, the remote target (GDBserver)
can do range stepping, and support single step, but GDB may decide to
resume instructions in the scratchpad rather than single step them one
by one for displaced stepping. For example, when aarch64 GDB debugs
arm linux program with aarch64 GDBserver, GDBserver supports both range
stepping and single step, but GDB (with the gdbarch for arm-linux)
decides resume instructions in the scratchpad, so in the RSP traffic,
there is no vCont;s packet at all, and some range-stepping.exp tests
fail,
FAIL: gdb.base/range-stepping.exp: multi insns: next: vCont;s=1 vCont;r=1
This patch is to get rid of the checking to the number of vCont;s in
exec_cmd_expect_vCont_count.
gdb/testsuite:
2015-10-21 Yao Qi <yao.qi@linaro.org>
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Remove argument exp_vCont_s.
* gdb.base/range-stepping.exp: Callers updated.
* gdb.trace/range-stepping.exp: Likewise.
2015-10-21 15:16:25 +00:00
|
|
|
if { $r_counter == ${exp_vCont_r} } {
|
2013-05-23 17:19:05 +00:00
|
|
|
pass $test
|
2013-05-24 09:57:12 +00:00
|
|
|
set ret 0
|
2013-05-23 17:19:05 +00:00
|
|
|
} else {
|
|
|
|
fail $test
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
gdb_test_no_output "set debug remote 0" ""
|
2013-05-24 09:57:12 +00:00
|
|
|
return $ret
|
2013-05-23 17:19:05 +00:00
|
|
|
}
|
2015-07-15 13:33:32 +00:00
|
|
|
|
|
|
|
# Check whether range stepping is supported by the target.
|
|
|
|
|
|
|
|
proc gdb_range_stepping_enabled { } {
|
|
|
|
global gdb_prompt
|
|
|
|
|
|
|
|
set command "set range-stepping on"
|
|
|
|
set message "probe range-stepping support"
|
|
|
|
gdb_test_multiple $command $message {
|
|
|
|
-re "Range stepping is not supported.*\r\n$gdb_prompt $" {
|
|
|
|
pass $message
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
-re "^$command\r\n$gdb_prompt $" {
|
|
|
|
pass $message
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0
|
|
|
|
}
|