mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-24 12:35:55 +08:00
4dfef5be68
As follow-up to this discussion: https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html ... make runto_main not pass no-message to runto. This means that if we fail to run to main, for some reason, we'll emit a FAIL. This is the behavior we want the majority of (if not all) the time. Without this, we rely on tests logging a failure if runto_main fails, otherwise. They do so in a very inconsisteny mannet, sometimes using "fail", "unsupported" or "untested". The messages also vary widly. This patch removes all these messages as well. Also, remove a few "fail" where we call runto (and not runto_main). by default (without an explicit no-message argument), runto prints a failure already. In two places, gdb.multi/multi-re-run.exp and gdb.python/py-pp-registration.exp, remove "message" passed to runto. This removes a few PASSes that we don't care about (but FAILs will still be printed if we fail to run to where we want to). This aligns their behavior with the rest of the testsuite. Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
62 lines
2.2 KiB
Plaintext
62 lines
2.2 KiB
Plaintext
# This testcase is part of GDB, the GNU debugger.
|
|
|
|
# Copyright 2010-2021 Free Software Foundation, Inc.
|
|
|
|
# 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/>.
|
|
|
|
# Test GDB bug report 11531.
|
|
# This is a problem related to CANNOT_STEP_HW_WATCHPOINTS macro.
|
|
# It affects Solaris native targets.
|
|
|
|
|
|
standard_testfile
|
|
|
|
if { [prepare_for_testing "failed to prepare" $testfile $testfile.c {debug}] } {
|
|
return -1
|
|
}
|
|
|
|
# Disable hardware watchpoints if necessary.
|
|
if [target_info exists gdb,no_hardware_watchpoints] {
|
|
gdb_test_no_output "set can-use-hw-watchpoints 0" ""
|
|
}
|
|
|
|
if { ![runto_main] } then {
|
|
return
|
|
}
|
|
|
|
# The breakpoint is probably at the instruction where the value being
|
|
# watched (myrec.x) gets updated. This is the instruction where we
|
|
# expect to receive a watchpoint notification when we do the "stepi"
|
|
# below. However, having the breakpoint at the same location as this
|
|
# intruction can possibly interfere with our testcase, as stepping
|
|
# over the breakpoint in order to get past it may incorrectly lead
|
|
# to the debugger missing the watchpoint hit. This would be a bug
|
|
# in GDB, but this is not the bug that we are trying to test here.
|
|
# So, we remove all breakpoints first.
|
|
|
|
delete_breakpoints
|
|
|
|
set nl "\[\r\n\]+"
|
|
|
|
gdb_test "watch myrec.x" ".*atchpoint \[0-9\]+: myrec\.x" "set watchpoint"
|
|
|
|
gdb_test "next" \
|
|
".*${nl}.*atchpoint \[0-9\]+: myrec\.x${nl}Old value = 0${nl}New value = 5${nl}.*" \
|
|
"watchpoint variable triggers at next"
|
|
|
|
gdb_test "continue" \
|
|
".*${nl}.*atchpoint \[0-9\]+: myrec\.x${nl}Old value = 5${nl}New value = 78${nl}.*" \
|
|
"watchpoint variable triggers at continue"
|
|
|