This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH, ppc] Fix hw *points for embedded ppc in a threaded environment.
- From: Pedro Alves <palves at redhat dot com>
- To: lgustavo at codesourcery dot com
- Cc: gdb-patches at sourceware dot org, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Date: Tue, 22 Jan 2013 12:11:46 +0000
- Subject: Re: [PATCH, ppc] Fix hw *points for embedded ppc in a threaded environment.
- References: <501FD5D6.30005@mentor.com> <50DCA690.6000606@codesourcery.com>
Hi Luis,
On 12/27/2012 07:50 PM, Luis Machado wrote:
>
> This is an updated patch that includes a generic testcase.
>
> The fix is still the same, but the testcase exercises creation of
> hardware watchpoints and their replication to all existing threads.
>
> Each thread should cause a watchpoint trigger a certain number of
> times, and that's what we expect in the testcase.
>
> Without the fix, the affected ppc targets will throw an error after
> the third thread gets created.
>
> Curiously, x86 misses a watchpoint trigger every once in a while.
> Since only a single trigger is allowed per thread at a given time,
> that is, we try our best not to cause multiple triggers at once,
> this may be a different issue, not directly related to the testcase.
>
> It would be nice if someone could try this testcase on different
> targets and confirm how it behaves, as well as validate the overall
> testcase format.
I'm looking at this, but I'd like to make sure I'm looking
at the correct patch.
> + # Some targets do resource counting as we insert watchpoints.
> + # Such targets won't cause a watchpoint insertion failure, but
> + # will switch to software watchpoints silently. We check for
> + # both cases here.
> + gdb_test_multiple "watch watched_data\[$hwatch_count\]" \
> + "watch watched_data\[$hwatch_count\]" {
> + -re "Hardware watchpoint .*" {
> + continue
Because, testing on x86_64, this "continue" here makes it
so that hwatch_count is never incremented at all (that bit is
below, and never gets a chance to run).
> + }
> + -re "Watchpoint .*" {
> + set done 1
> + break
> + }
> + }
Also, both these patterns miss expecting the prompt, leading to
races. Here's the patch I'm using on top of yours:
diff --git c/gdb/testsuite/gdb.threads/watchthreads3.exp w/gdb/testsuite/gdb.threads/watchthreads3.exp
index e2ee228..c958b31 100644
--- c/gdb/testsuite/gdb.threads/watchthreads3.exp
+++ w/gdb/testsuite/gdb.threads/watchthreads3.exp
@@ -68,10 +68,10 @@ while { $done == 0 } {
# both cases here.
gdb_test_multiple "watch watched_data\[$hwatch_count\]" \
"watch watched_data\[$hwatch_count\]" {
- -re "Hardware watchpoint .*" {
- continue
+ -re "Hardware watchpoint .*$gdb_prompt $" {
+# continue
}
- -re "Watchpoint .*" {
+ -re "Watchpoint .*$gdb_prompt $" {
set done 1
break
}
On 12/27/2012 07:50 PM, Luis Machado wrote:
> Curiously, x86 misses a watchpoint trigger every once in a while.
> Since only a single trigger is allowed per thread at a given time,
> that is, we try our best not to cause multiple triggers at once,
> this may be a different issue, not directly related to the testcase.
I set the test to run in an inf loop, and I saw this after a few
iterations:
FAIL: gdb.threads/watchthreads3.exp: Continue to watchpoint trigger on watched_data (the program exited)
=== gdb Summary ===
# of expected passes 177
# of unexpected failures 1
I guess that's what you referred to.
--
Pedro Alves