From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5718 invoked by alias); 22 Jan 2013 12:12:02 -0000 Received: (qmail 5700 invoked by uid 22791); 22 Jan 2013 12:12:01 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jan 2013 12:11:50 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0MCBmma010692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jan 2013 07:11:48 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0MCBkQb009944; Tue, 22 Jan 2013 07:11:47 -0500 Message-ID: <50FE8202.3040106@redhat.com> Date: Tue, 22 Jan 2013 12:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: lgustavo@codesourcery.com CC: gdb-patches@sourceware.org, Jan Kratochvil Subject: Re: [PATCH, ppc] Fix hw *points for embedded ppc in a threaded environment. References: <501FD5D6.30005@mentor.com> <50DCA690.6000606@codesourcery.com> In-Reply-To: <50DCA690.6000606@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00523.txt.bz2 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