* [RFA]: threaded watchpoint test
@ 2004-07-27 18:56 Jeff Johnston
2004-07-27 22:56 ` Michael Chastain
2004-07-27 23:02 ` Daniel Jacobowitz
0 siblings, 2 replies; 11+ messages in thread
From: Jeff Johnston @ 2004-07-27 18:56 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
The attached patch adds a testcase to test that hardware watchpoints trigger in
threads. At present, this support does not work, but it is not tested anywhere.
With uncommited patches, I have the test working for x86 and ia64.
The test only bothers if hardware watchpoints are supported.
Ok to commit?
-- Jeff J.
2004-07-27 Jeff Johnston <jjohnstn@redhat.com>
* gdb.threads/watchthreads.exp: New test for threaded watchpoints.
[-- Attachment #2: watchthreads.patch --]
[-- Type: text/plain, Size: 4295 bytes --]
Index: gdb.threads/watchthreads.exp
===================================================================
RCS file: gdb.threads/watchthreads.exp
diff -N gdb.threads/watchthreads.exp
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ gdb.threads/watchthreads.exp 27 Jul 2004 18:55:29 -0000
@@ -0,0 +1,125 @@
+# This testcase is part of GDB, the GNU debugger.
+
+# Copyright 2004 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 2 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, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+# Check that GDB can support multiple watchpoints across threads.
+
+if $tracelevel {
+ strace $tracelevel
+}
+
+set prms_id 0
+set bug_id 0
+
+# This test verifies that a watchpoint is detected in the proper thread
+# so the test is only meaningful on a system with hardware watchpoints.
+if [target_info exists gdb,no_hardware_watchpoints] {
+ return 0;
+}
+
+set testfile "schedlock"
+set srcfile ${testfile}.c
+set binfile ${objdir}/${subdir}/${testfile}
+if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable [list debug "incdir=${objdir}"]] != "" } {
+ return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+gdb_test "set can-use-hw-watchpoints 1" "" ""
+
+#
+# Run to `main' where we begin our tests.
+#
+
+if ![runto_main] then {
+ gdb_suppress_tests
+}
+
+set args_0 0
+set args_1 0
+
+# Watch values that will be modified by distinct threads.
+gdb_test "watch args\[0\]" "Hardware watchpoint 2: args\\\[0\\\]"
+gdb_test "watch args\[1\]" "Hardware watchpoint 3: args\\\[1\\\]"
+
+# Loop and continue to allow both watchpoints to be triggered.
+for {set i 0} {$i < 30} {incr i} {
+ set test_flag 0
+ gdb_test_multiple "continue" "threaded watch loop" {
+ -re "Hardware watchpoint 2: args\\\[0\\\].*Old value = 0.*New value = 1.*main \\\(\\\) at .*schedlock.c:21.*$gdb_prompt $"
+ { set args_0 1; set test_flag 1 }
+ -re "Hardware watchpoint 3: args\\\[1\\\].*Old value = 0.*New value = 1.*main \\\(\\\) at .*schedlock.c:21.*$gdb_prompt $"
+ { set args_1 1; set test_flag 1 }
+ -re "Hardware watchpoint 2: args\\\[0\\\].*Old value = $args_0.*New value = [expr $args_0+1].*in thread_function \\\(arg=0x0\\\) at .*schedlock.c:42.*$gdb_prompt $"
+ { set args_0 [expr $args_0+1]; set test_flag 1 }
+ -re "Hardware watchpoint 3: args\\\[1\\\].*Old value = $args_1.*New value = [expr $args_1+1].*in thread_function \\\(arg=0x1\\\) at .*schedlock.c:42.*$gdb_prompt $"
+ { set args_1 [expr $args_1+1]; set test_flag 1 }
+ }
+ # If we fail above, don't bother continuing loop
+ if { $test_flag == 0 } {
+ set i 30;
+ }
+}
+
+# Print success message if loop succeeded.
+if { $test_flag == 1 } {
+ pass "threaded watch loop"
+}
+
+# Verify that we hit first watchpoint in main thread.
+set message "first watchpoint on args\[0\] hit"
+if { $args_0 > 0 } {
+ pass $message
+} else {
+ fail $message
+}
+
+# Verify that we hit second watchpoint in main thread.
+set message "first watchpoint on args\[1\] hit"
+if { $args_1 > 0 } {
+ pass $message
+} else {
+ fail $message
+}
+
+# Verify that we hit first watchpoint in child thread.
+set message "watchpoint on args\[0\] hit in thread"
+if { $args_0 > 1 } {
+ pass $message
+} else {
+ fail $message
+}
+
+# Verify that we hit second watchpoint in child thread.
+set message "watchpoint on args\[1\] hit in thread"
+if { $args_1 > 1 } {
+ pass $message
+} else {
+ fail $message
+}
+
+# Verify that all watchpoint hits are accounted for.
+set message "combination of threaded watchpoints = 30"
+if { [expr $args_0+$args_1] == 30 } {
+ pass $message
+} else {
+ fail $message
+}
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFA]: threaded watchpoint test
2004-07-27 18:56 [RFA]: threaded watchpoint test Jeff Johnston
@ 2004-07-27 22:56 ` Michael Chastain
2004-07-27 23:02 ` Daniel Jacobowitz
1 sibling, 0 replies; 11+ messages in thread
From: Michael Chastain @ 2004-07-27 22:56 UTC (permalink / raw)
To: jjohnstn, gdb-patches
This patch is approved. Thanks.
Michael C
> 2004-07-27 Jeff Johnston <jjohnstn@redhat.com>
>
> * gdb.threads/watchthreads.exp: New test for threaded
> watchpoints.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFA]: threaded watchpoint test
2004-07-27 18:56 [RFA]: threaded watchpoint test Jeff Johnston
2004-07-27 22:56 ` Michael Chastain
@ 2004-07-27 23:02 ` Daniel Jacobowitz
2004-07-27 23:24 ` Jeff Johnston
1 sibling, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2004-07-27 23:02 UTC (permalink / raw)
To: Jeff Johnston; +Cc: gdb-patches
On Tue, Jul 27, 2004 at 02:56:19PM -0400, Jeff Johnston wrote:
> +# Watch values that will be modified by distinct threads.
> +gdb_test "watch args\[0\]" "Hardware watchpoint 2: args\\\[0\\\]"
> +gdb_test "watch args\[1\]" "Hardware watchpoint 3: args\\\[1\\\]"
What about platforms without hardware watchpoints? This test will
generate a lot of FAILs in that case.
Not to mention targets with only one hardware watchpoint; I'm not sure
if there are any.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFA]: threaded watchpoint test
2004-07-27 23:02 ` Daniel Jacobowitz
@ 2004-07-27 23:24 ` Jeff Johnston
2004-07-27 23:27 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Jeff Johnston @ 2004-07-27 23:24 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
> On Tue, Jul 27, 2004 at 02:56:19PM -0400, Jeff Johnston wrote:
>
>>+# Watch values that will be modified by distinct threads.
>>+gdb_test "watch args\[0\]" "Hardware watchpoint 2: args\\\[0\\\]"
>>+gdb_test "watch args\[1\]" "Hardware watchpoint 3: args\\\[1\\\]"
>
>
> What about platforms without hardware watchpoints? This test will
> generate a lot of FAILs in that case.
>
I mentioned this both in my original posting and in the test case itself. There
is a test for hardware watchpoints and if there are no hardware watchpoints, it
returns 0.
# This test verifies that a watchpoint is detected in the proper thread
# so the test is only meaningful on a system with hardware watchpoints.
if [target_info exists gdb,no_hardware_watchpoints] {
return 0;
}
> Not to mention targets with only one hardware watchpoint; I'm not sure
> if there are any.
>
Don't know of any myself, but I will be happy to add tests for such platforms if
somebody points them out.
-- Jeff J.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFA]: threaded watchpoint test
2004-07-27 23:24 ` Jeff Johnston
@ 2004-07-27 23:27 ` Daniel Jacobowitz
2004-07-27 23:41 ` Jeff Johnston
2004-07-28 0:13 ` Michael Chastain
0 siblings, 2 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2004-07-27 23:27 UTC (permalink / raw)
To: Jeff Johnston; +Cc: gdb-patches
On Tue, Jul 27, 2004 at 07:24:31PM -0400, Jeff Johnston wrote:
> Daniel Jacobowitz wrote:
> >On Tue, Jul 27, 2004 at 02:56:19PM -0400, Jeff Johnston wrote:
> >
> >>+# Watch values that will be modified by distinct threads.
> >>+gdb_test "watch args\[0\]" "Hardware watchpoint 2: args\\\[0\\\]"
> >>+gdb_test "watch args\[1\]" "Hardware watchpoint 3: args\\\[1\\\]"
> >
> >
> >What about platforms without hardware watchpoints? This test will
> >generate a lot of FAILs in that case.
> >
>
> I mentioned this both in my original posting and in the test case itself.
> There is a test for hardware watchpoints and if there are no hardware
> watchpoints, it returns 0.
>
> # This test verifies that a watchpoint is detected in the proper thread
> # so the test is only meaningful on a system with hardware watchpoints.
> if [target_info exists gdb,no_hardware_watchpoints] {
> return 0;
> }
OK. Unfortunately I don't think this test is conclusive; unix.exp will
always claim to have hardware watchpoints, and on many systems it does
not (for instance powerpc-linux). If that turns out to be true we can
introduce gdb_has_hardware_watchpoints or something along those lines.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFA]: threaded watchpoint test
2004-07-27 23:27 ` Daniel Jacobowitz
@ 2004-07-27 23:41 ` Jeff Johnston
2004-07-28 0:13 ` Michael Chastain
1 sibling, 0 replies; 11+ messages in thread
From: Jeff Johnston @ 2004-07-27 23:41 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
Daniel Jacobowitz wrote:
> On Tue, Jul 27, 2004 at 07:24:31PM -0400, Jeff Johnston wrote:
>
>>Daniel Jacobowitz wrote:
>>
>>>On Tue, Jul 27, 2004 at 02:56:19PM -0400, Jeff Johnston wrote:
>>>
>>>
>>>>+# Watch values that will be modified by distinct threads.
>>>>+gdb_test "watch args\[0\]" "Hardware watchpoint 2: args\\\[0\\\]"
>>>>+gdb_test "watch args\[1\]" "Hardware watchpoint 3: args\\\[1\\\]"
>>>
>>>
>>>What about platforms without hardware watchpoints? This test will
>>>generate a lot of FAILs in that case.
>>>
>>
>>I mentioned this both in my original posting and in the test case itself.
>>There is a test for hardware watchpoints and if there are no hardware
>>watchpoints, it returns 0.
>>
>># This test verifies that a watchpoint is detected in the proper thread
>># so the test is only meaningful on a system with hardware watchpoints.
>>if [target_info exists gdb,no_hardware_watchpoints] {
>> return 0;
>>}
>
>
> OK. Unfortunately I don't think this test is conclusive; unix.exp will
> always claim to have hardware watchpoints, and on many systems it does
> not (for instance powerpc-linux). If that turns out to be true we can
> introduce gdb_has_hardware_watchpoints or something along those lines.
>
Ok. I have just checked in the test.
-- Jeff J.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFA]: threaded watchpoint test
2004-07-27 23:27 ` Daniel Jacobowitz
2004-07-27 23:41 ` Jeff Johnston
@ 2004-07-28 0:13 ` Michael Chastain
2004-07-29 15:26 ` Daniel Jacobowitz
1 sibling, 1 reply; 11+ messages in thread
From: Michael Chastain @ 2004-07-28 0:13 UTC (permalink / raw)
To: jjohnstn, drow; +Cc: gdb-patches
> OK. Unfortunately I don't think this test is conclusive; unix.exp will
> always claim to have hardware watchpoints, and on many systems it does
> not (for instance powerpc-linux). If that turns out to be true we can
> introduce gdb_has_hardware_watchpoints or something along those lines.
Yeah, I'm a bit leery of "set_board_info gdb,no_hardware_watchpoints"
but it already exists (although not used for that purpose).
I missed something, though:
if [target_info exists gdb,no_hardware_watchpoints] {
return 0;
}
Perhaps there should be an UNSUPPORTED in there before the "return 0":
unsupported "hardware watchpoints on this target"
Daniel, what do you think?
Michael C
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFA]: threaded watchpoint test
2004-07-28 0:13 ` Michael Chastain
@ 2004-07-29 15:26 ` Daniel Jacobowitz
2004-07-29 23:39 ` Mark Kettenis
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2004-07-29 15:26 UTC (permalink / raw)
To: Michael Chastain; +Cc: jjohnstn, gdb-patches
On Tue, Jul 27, 2004 at 08:12:42PM -0400, Michael Chastain wrote:
> > OK. Unfortunately I don't think this test is conclusive; unix.exp will
> > always claim to have hardware watchpoints, and on many systems it does
> > not (for instance powerpc-linux). If that turns out to be true we can
> > introduce gdb_has_hardware_watchpoints or something along those lines.
>
> Yeah, I'm a bit leery of "set_board_info gdb,no_hardware_watchpoints"
> but it already exists (although not used for that purpose).
>
> I missed something, though:
>
> if [target_info exists gdb,no_hardware_watchpoints] {
> return 0;
> }
>
> Perhaps there should be an UNSUPPORTED in there before the "return 0":
>
> unsupported "hardware watchpoints on this target"
>
> Daniel, what do you think?
Sounds good to me. We'll probably want to clean up the other bit about
using the board_info too; or... just recognize that we got a software
watchpoint instead of a hardware one?
Maybe not. It could be a bug to get a software watchpoint when we
expect a hardware one. The question is whether we want to keep a
separate list of "do we expect hardware watchpoints" in the testsuite.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFA]: threaded watchpoint test
2004-07-29 15:26 ` Daniel Jacobowitz
@ 2004-07-29 23:39 ` Mark Kettenis
2004-07-30 0:55 ` Michael Chastain
0 siblings, 1 reply; 11+ messages in thread
From: Mark Kettenis @ 2004-07-29 23:39 UTC (permalink / raw)
To: drow; +Cc: mec.gnu, jjohnstn, gdb-patches
Date: Thu, 29 Jul 2004 11:25:18 -0400
From: Daniel Jacobowitz <drow@false.org>
Sounds good to me. We'll probably want to clean up the other bit about
using the board_info too; or... just recognize that we got a software
watchpoint instead of a hardware one?
Maybe not. It could be a bug to get a software watchpoint when we
expect a hardware one. The question is whether we want to keep a
separate list of "do we expect hardware watchpoints" in the testsuite.
Hmm, I'm getting a bit frustrated that folks keep adding things to the
testsuite that assume features that are not available on most things
not i386 GNU/Linux.
Why do we allow tests like this to be checked in if we know they
produce massive fails on many systems?
Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFA]: threaded watchpoint test
2004-07-29 23:39 ` Mark Kettenis
@ 2004-07-30 0:55 ` Michael Chastain
2004-07-30 22:33 ` Andrew Cagney
0 siblings, 1 reply; 11+ messages in thread
From: Michael Chastain @ 2004-07-30 0:55 UTC (permalink / raw)
To: kettenis, drow; +Cc: jjohnstn, gdb-patches
Mark Kettenis writes:
mark> Why do we allow tests like this to be checked in if we know they
mark> produce massive fails on many systems?
To take the philosophical question first: there's no registry of
which systems are actually tested with gdb. The list of posts to
gdb-testers@ is the only thing I have. If a system is not
represented there then I pay less attention to it.
Hmmm, this is in gdb.threads, I should not even have approved this
patch in the first place! I apologize to Michael Snyder.
mark> Hmm, I'm getting a bit frustrated that folks keep adding things to the
mark> testsuite that assume features that are not available on most things
mark> not i386 GNU/Linux.
I hear you.
Daniel Jacobowitz writes:
drow> Maybe not. It could be a bug to get a software watchpoint when we
drow> expect a hardware one. The question is whether we want to keep a
drow> separate list of "do we expect hardware watchpoints" in the testsuite.
I think so, but I'm not sure.
Two possible approaches are:
(1) The test suite does not keep its own info. The test suite asks
gdb whether gdb supports feature X, and trusts gdb.
(2) The test suite keeps separate info. That way, the test suite
is actually testing gdb, not just asking and trusting it.
But the info can get out of sync.
(2A) A whitelist of systems to test.
(2B) A blacklist of systems not to test.
I'm inclined to some form of (2). I don't like (1) because the test
suite is supposed to *test* gdb, not just trust gdb's answers.
Also, I don't know any existing gdb command to ask this question.
On the other hand, hardware watchpoints are not meant to work on
all systems, so it might be reasonable to ask gdb about them.
gdb.base/bigcore.exp is a big test that uses (2). First it blacklists
all the !isnative systems. Then it blacklists four specific systems:
bsd, hpux, solaris, cygwin.
For hardware watchpoint tests, the blacklist would be pretty long.
That's okay with me, it's just painful to set up the first time.
What do y'all think?
Michael C
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RFA]: threaded watchpoint test
2004-07-30 0:55 ` Michael Chastain
@ 2004-07-30 22:33 ` Andrew Cagney
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Cagney @ 2004-07-30 22:33 UTC (permalink / raw)
To: Michael Chastain; +Cc: kettenis, drow, jjohnstn, gdb-patches
> (1) The test suite does not keep its own info. The test suite asks
> gdb whether gdb supports feature X, and trusts gdb.
>
> (2) The test suite keeps separate info. That way, the test suite
> is actually testing gdb, not just asking and trusting it.
> But the info can get out of sync.
>
> (2A) A whitelist of systems to test.
>
> (2B) A blacklist of systems not to test.
We need both:
- the testsuite asks and trusts GDB if feature X is supported
- cross-check test confirming that GDB matches theory
That way as each feature is implemented, the testsuite's coverage
expands accordingly. But, if there's a screwup, the cross-check detects
the problem.
Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-07-30 22:33 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-27 18:56 [RFA]: threaded watchpoint test Jeff Johnston
2004-07-27 22:56 ` Michael Chastain
2004-07-27 23:02 ` Daniel Jacobowitz
2004-07-27 23:24 ` Jeff Johnston
2004-07-27 23:27 ` Daniel Jacobowitz
2004-07-27 23:41 ` Jeff Johnston
2004-07-28 0:13 ` Michael Chastain
2004-07-29 15:26 ` Daniel Jacobowitz
2004-07-29 23:39 ` Mark Kettenis
2004-07-30 0:55 ` Michael Chastain
2004-07-30 22:33 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox