This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, ppc] Fix hw *points for embedded ppc in a threaded environment.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]