From: Pedro Alves <palves@redhat.com>
To: lgustavo@codesourcery.com
Cc: gdb-patches@sourceware.org, Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [PATCH, ppc] Fix hw *points for embedded ppc in a threaded environment.
Date: Tue, 22 Jan 2013 12:12:00 -0000 [thread overview]
Message-ID: <50FE8202.3040106@redhat.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2013-01-22 12:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-06 14:33 Luis Gustavo
2012-08-06 18:40 ` Jan Kratochvil
2012-08-06 19:02 ` Luis Gustavo
2012-08-06 20:28 ` Jan Kratochvil
2012-08-07 14:55 ` Luis Gustavo
2012-08-07 15:00 ` Jan Kratochvil
2012-08-07 15:02 ` Luis Gustavo
2012-12-27 19:50 ` Luis Machado
2013-01-22 12:12 ` Pedro Alves [this message]
2013-04-17 20:33 Luis Machado
2013-04-18 0:19 ` Sergio Durigan Junior
2013-04-18 0:51 ` Luis Machado
2013-04-22 21:09 ` Luis Machado
2013-04-22 21:09 ` Pedro Alves
2013-04-23 0:05 ` Pedro Alves
2013-04-23 1:15 ` Pedro Alves
2013-04-23 20:25 ` Luis Machado
2013-04-23 23:18 ` Luis Machado
2013-04-24 3:19 ` Pedro Alves
2013-04-24 6:28 ` Luis Machado
2013-04-24 19:04 ` Pedro Alves
2013-04-25 14:13 ` Luis Machado
2013-05-07 7:44 ` Luis Machado
2013-04-24 4:36 ` Pedro Alves
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=50FE8202.3040106@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=lgustavo@codesourcery.com \
/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