Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Simon Marchi <simark@simark.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/testsuite: Run test when software watchpoints are used
Date: Fri, 06 Jul 2018 23:21:00 -0000	[thread overview]
Message-ID: <20180706232109.GR2675@embecosm.com> (raw)
In-Reply-To: <25d43a27477e9ac14c7a0a4dad19d580@simark.ca>

* Simon Marchi <simark@simark.ca> [2018-07-06 10:43:49 -0400]:

> On 2018-07-06 09:59, Andrew Burgess wrote:
> > I think you give me too much credit!
> > 
> > What happened was I had a target without h/w watchpoints, I ran the
> > GDB testsuite and had a set of passes and fails.  After some
> > investigation I realised that I'd neglected to mark the target as not
> > supporting h/w watchpoints in the board file.
> > 
> > Once I'd added the no h/w watchpoint flag in the board file I reran
> > the tests, and mostly things looked better.  Failures, or unresolved
> > tests had become unsupported.
> > 
> > However.... in watchpoint-reuse-slot.exp a number of tests that used
> > to pass had gone away, so I went looking at the test script.
> > 
> > What I saw was that though the test declared a need for h/w
> > watchpoints, the test would run perfectly fine without them.
> > 
> > You'll notice that with my change if the board file says that h/w
> > watchpoints are supported then we still look for the full "Hardware
> > watchpoint" pattern in the output, that is, my change does not mean
> > that if GDB broke and h/w watchpoints changed to s/w watchpoints (when
> > they shouldn't) the test would pass.  I think that after my change all
> > targets that previously ran this test are just as well tested as they
> > ever were.
> > 
> > But, we have additional s/w watchpoint testing for targets that don't
> > support h/w watchpoints.  Is this testing anything that's not covered
> > elsewhere?  Honestly, I don't know.  There probably is a lot of test
> > duplication, but I can't guarantee that there's nothing unique in
> > here.
> > 
> > I guess my question is, what's the harm from broadening the test in
> > this way?  If I've missed something and this change could mean a bug
> > can now slip into GDB then absolutely, this is not acceptable.  But, I
> > can't see how (yet)...
> 
> Indeed, I see no harm in running more tests, at worst it's useless.  Maybe
> it will find some bug in the software watchpoint code.
> 
> I was thinking that we might as well run it with software watchpoints even
> with targets that support hardware watchpoints.  We could run
> unconditionally
> with "set can-use-hw-watchpoints 0" and run it with "1" on targets that
> support hw watchpoints.

OK, got you, something like this then:

Thanks,
Andrew

---

[PATCH] gdb/testsuite: Run test with software and hardware watchpoints

Expand the gdb.base/watchpoint-reuse-slot.exp test to be run twice,
once with hardware watchpoints disabled (this is new) and then with
hardware watchpoints enabled (the old way).

Running with hardware watchpoints enabled is skipped if the board file
says that hardware watchpoints are not supported on this target.

gdb/testsuite/ChangeLog:

	* gdb.base/watchpoint-reuse-slot.exp: Test with hardware
	watchpoints disabled and then enabled.
---
 gdb/testsuite/ChangeLog                          |   5 +
 gdb/testsuite/gdb.base/watchpoint-reuse-slot.exp | 170 ++++++++++++++---------
 2 files changed, 108 insertions(+), 67 deletions(-)

diff --git a/gdb/testsuite/gdb.base/watchpoint-reuse-slot.exp b/gdb/testsuite/gdb.base/watchpoint-reuse-slot.exp
index f196b89eab7..b1d7b14206e 100644
--- a/gdb/testsuite/gdb.base/watchpoint-reuse-slot.exp
+++ b/gdb/testsuite/gdb.base/watchpoint-reuse-slot.exp
@@ -22,11 +22,6 @@
 # operation.  (Note that we don't have any of these watchpoints
 # trigger.)
 
-if [target_info exists gdb,no_hardware_watchpoints] {
-    unsupported "no target support"
-    return
-}
-
 standard_testfile
 
 if {[prepare_for_testing "failed to prepare" $testfile $srcfile debug]} {
@@ -85,54 +80,62 @@ proc stepi {} {
 
 gdb_breakpoint $srcline
 gdb_continue_to_breakpoint "stepi line"
+set cur_addr [get_pc]
 
 # The test tries various sequences of different types of watchpoints.
 # Probe for support first.
+proc build_cmds_list {} {
+    global gdb_prompt
+
+    # So we get an immediate warning/error if the target doesn't support a
+    # given watchpoint type.
+    gdb_test_no_output "set breakpoint always-inserted on" \
+	"Set breakpoints always inserted while building cmds list"
+
+    # The list of supported commands.  Below we'll probe for support and
+    # add elements to this list.
+    set cmds {}
+
+    foreach cmd {"watch" "awatch" "rwatch"} {
+	set test $cmd
+	gdb_test_multiple "$cmd buf.byte\[0\]" $test {
+	    -re "You may have requested too many.*$gdb_prompt $" {
+		unsupported $test
+	    }
+	    -re "Target does not support.*$gdb_prompt $" {
+		unsupported $test
+	    }
+	    -re "Can't set read/access watchpoint when hardware watchpoints are disabled.*$gdb_prompt $" {
+		unsupported $test
+	    }
+	    -re "$gdb_prompt $" {
+		pass $test
+		lappend cmds $cmd
+	    }
+	}
 
-# So we get an immediate warning/error if the target doesn't support a
-# given watchpoint type.
-gdb_test_no_output "set breakpoint always-inserted on"
-
-# The list of supported commands.  Below we'll probe for support and
-# add elements to this list.
-set cmds {}
+	delete_breakpoints
+    }
 
-foreach cmd {"watch" "awatch" "rwatch"} {
-    set test $cmd
-    gdb_test_multiple "$cmd buf.byte\[0\]" $test {
+    set test "hbreak"
+    gdb_test_multiple "hbreak main" $test {
 	-re "You may have requested too many.*$gdb_prompt $" {
 	    unsupported $test
 	}
-	-re "Target does not support.*$gdb_prompt $" {
+	-re "No hardware breakpoint support.*$gdb_prompt $" {
 	    unsupported $test
 	}
 	-re "$gdb_prompt $" {
 	    pass $test
-	    lappend cmds $cmd
+	    lappend cmds "hbreak"
 	}
     }
 
-   delete_breakpoints
-}
+    delete_breakpoints
 
-set test "hbreak"
-gdb_test_multiple "hbreak main" $test {
-    -re "You may have requested too many.*$gdb_prompt $" {
-	unsupported $test
-    }
-    -re "No hardware breakpoint support.*$gdb_prompt $" {
-	unsupported $test
-    }
-    -re "$gdb_prompt $" {
-	pass $test
-	lappend cmds "hbreak"
-    }
+    return $cmds
 }
 
-delete_breakpoints
-
-set cur_addr [get_pc]
-
 # Return true if the memory range [buf.byte + OFFSET, +WIDTH] can be
 # monitored by CMD, otherwise return false.
 
@@ -183,9 +186,10 @@ proc valid_addr_p {cmd offset width} {
 }
 
 # Watch WIDTH bytes at BASE + OFFSET.  CMD specifices the specific
-# type of watchpoint to use.  If CMD is "hbreak", WIDTH is ignored.
+# type of watchpoint to use.  If CMD is "hbreak", WIDTH is ignored.  The
+# HW_WP_P flag tells us if harware watchpoints are enabled or not.
 
-proc watch_command {cmd base offset width} {
+proc watch_command {cmd base offset width hw_wp_p} {
     global srcfile srcline hex
 
     if {$cmd == "hbreak"} {
@@ -193,8 +197,15 @@ proc watch_command {cmd base offset width} {
 	gdb_test "hbreak $expr" "Hardware assisted breakpoint \[0-9\]+ at $hex"
     } elseif {$cmd == "watch"} {
 	set expr "*(buf.byte + $base + $offset)@$width"
+
+	if { ! $hw_wp_p } {
+	    set wp_prefix "Watchpoint"
+	} else {
+	    set wp_prefix "Hardware watchpoint"
+	}
+
 	gdb_test "$cmd $expr" \
-	    "Hardware watchpoint \[0-9\]+: [string_to_regexp $expr]"
+	    "${wp_prefix} \[0-9\]+: [string_to_regexp $expr]"
     } elseif {$cmd == "awatch"} {
 	set expr "*(buf.byte + $base + $offset)@$width"
 	gdb_test "$cmd $expr" \
@@ -206,42 +217,48 @@ proc watch_command {cmd base offset width} {
     }
 }
 
-# Run test proper.  See intro for description.
-
-foreach always_inserted {"off" "on" } {
-    gdb_test_no_output "set breakpoint always-inserted $always_inserted"
-    foreach cmd1 $cmds {
-	foreach cmd2 $cmds {
-	    for {set width 1} {$width < 4} {incr width} {
+# Run the watchpoint tests (see the description at the top for details), the
+# HW_WP_P flag tells us if hardware watchpoints are enabled or not.
+proc run_watchpoints_tests {hw_wp_p} {
 
-		if {$cmd1 == "hbreak" && $cmd2 == "hbreak" && $width > 1} {
-		    # hbreak ignores WIDTH, no use testing more than
-		    # once.
-		    continue
-		}
+    set cmds [build_cmds_list]
 
-		for {set x 0} {$x < 4} {incr x} {
+    foreach always_inserted {"off" "on" } {
+	gdb_test_no_output "set breakpoint always-inserted $always_inserted"
+	foreach cmd1 $cmds {
+	    foreach cmd2 $cmds {
+		for {set width 1} {$width < 4} {incr width} {
 
-		    if { ![valid_addr_p $cmd1 $x $width]
-			 || ![valid_addr_p $cmd2 $x+1 $width] } {
-			# Skip tests if requested address or length
-			# of breakpoint or watchpoint don't meet
-			# target or kernel requirements.
+		    if {$cmd1 == "hbreak" && $cmd2 == "hbreak" \
+			    && $width > 1} {
+			# hbreak ignores WIDTH, no use testing more than
+			# once.
 			continue
 		    }
 
-		    set prefix "always-inserted $always_inserted: "
-		    append prefix "$cmd1 x $cmd2: "
-		    with_test_prefix "$prefix: width $width, iter $x" {
-			with_test_prefix "base + 0" {
-			    watch_command $cmd1 $x 0 $width
-			    stepi
-			    gdb_test_no_output "delete \$bpnum"
+		    for {set x 0} {$x < 4} {incr x} {
+
+			if { ![valid_addr_p $cmd1 $x $width]
+			     || ![valid_addr_p $cmd2 $x+1 $width] } {
+			    # Skip tests if requested address or length
+			    # of breakpoint or watchpoint don't meet
+			    # target or kernel requirements.
+			    continue
 			}
-			with_test_prefix "base + 1" {
-			    watch_command $cmd2 $x 1 $width
-			    stepi
-			    gdb_test_no_output "delete \$bpnum"
+
+			set prefix "always-inserted $always_inserted: "
+			append prefix "$cmd1 x $cmd2: "
+			with_test_prefix "$prefix: width $width, iter $x" {
+			    with_test_prefix "base + 0" {
+				watch_command $cmd1 $x 0 $width $hw_wp_p
+				stepi
+				gdb_test_no_output "delete \$bpnum"
+			    }
+			    with_test_prefix "base + 1" {
+				watch_command $cmd2 $x 1 $width $hw_wp_p
+				stepi
+				gdb_test_no_output "delete \$bpnum"
+			    }
 			}
 		    }
 		}
@@ -249,3 +266,22 @@ foreach always_inserted {"off" "on" } {
 	}
     }
 }
+
+# Run tests with hardware watchpoints disabled, then again with them
+# enabled (if this target supports hardware watchpoints).
+foreach hw_wp_p { 0 1 } {
+
+    if { $hw_wp_p } {
+	# Does this target support h/w watchpoints?
+	if [target_info exists gdb,no_hardware_watchpoints] { continue }
+	set prefix "hw-watch"
+    } else {
+	set prefix "sw-watch"
+    }
+
+    gdb_test_no_output "set can-use-hw-watchpoints ${hw_wp_p}"
+
+    with_test_prefix $prefix {
+	run_watchpoints_tests $hw_wp_p
+    }
+}
-- 
2.14.4


  reply	other threads:[~2018-07-06 23:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-04 16:40 Andrew Burgess
2018-07-06  2:53 ` Simon Marchi
2018-07-06 13:59   ` Andrew Burgess
2018-07-06 14:43     ` Simon Marchi
2018-07-06 23:21       ` Andrew Burgess [this message]
2018-07-07  0:47         ` Simon Marchi
2018-07-10 14:01           ` Andrew Burgess
2018-10-31 13:52             ` Phil Muldoon

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=20180706232109.GR2675@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /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