From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12470 invoked by alias); 5 Jul 2013 17:15:41 -0000 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 Received: (qmail 12456 invoked by uid 89); 5 Jul 2013 17:15:41 -0000 X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,KAM_TIME,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=no version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 05 Jul 2013 17:15:40 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Uv9bb-00046K-98 from Luis_Gustavo@mentor.com ; Fri, 05 Jul 2013 10:15:35 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 10:15:35 -0700 Received: from [172.30.14.191] ([172.30.14.191]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jul 2013 10:15:34 -0700 Message-ID: <51D6FF33.3010501@codesourcery.com> Date: Fri, 05 Jul 2013 17:15:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andreas Arnez CC: gdb-patches@sourceware.org Subject: Re: [PATCH] wp-replication: Fix test case loop References: <87ppuxasyo.fsf@br87z6lw.de.ibm.com> <51D6F295.2070306@codesourcery.com> <87li5laq6w.fsf@br87z6lw.de.ibm.com> In-Reply-To: <87li5laq6w.fsf@br87z6lw.de.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-07/txt/msg00206.txt.bz2 On 07/05/2013 02:09 PM, Andreas Arnez wrote: > Luis Machado writes: > >> On 07/05/2013 01:10 PM, Andreas Arnez wrote: >>> When executing wp-replication.exp on S/390, the loop that counts the >>> number of available hardware watchpoints does not terminate properly, >>> because *all* "watch" commands yield "hardware watchpoints". >>> >>> Since the C source code is not prepared for more than NR_THREADS >>> hardware watchpoints anyhow, I suggest to add the appropriate exit >>> condition to the loop. >> >> That's an interesting behavior. Are the resources on s390 nearly >> unlimited for hardware watchpoints? Does it run out of hardware >> watchpoints eventually? > > Well, that would be nice, wouldn't it? But sorry, no. On s390 the > hardware can generate so-called "PER storage alteration events" (PER = > program event recording) for a single contiguous memory area. > s390-nat.c chooses this area such that all desired watchpoints lie > within. > > Thus what happens in wp-replication.exp is that the PER ending address > is increased with every loop iteration, but no hardware limit is > reached. > I see now. Thanks. What do you think of forcing the testcase to use non-contiguous areas for the watchpoints instead of using a testcase that does not work/test properly for s390? What if we add watchpoints every x bytes or so? Would that be enough to make s390 give up on using a single hardware watchpoint for a big range of contiguous addresses? >> If s390 doesn't run out of hardware watchpoints, i'd add a comment to >> the testcase explaining why we have this condition. > > Sure. How about this then? > > > diff --git a/gdb/testsuite/gdb.threads/wp-replication.exp b/gdb/testsuite/gdb.threads/wp-replication.exp > index 8927a43..c6a13b9 100644 > --- a/gdb/testsuite/gdb.threads/wp-replication.exp > +++ b/gdb/testsuite/gdb.threads/wp-replication.exp > @@ -81,6 +81,14 @@ while { $done == 0 } { > gdb_test_multiple "continue" "watchpoint created successfully" { > -re ".*Breakpoint 2, empty_cycle \\(\\).*$gdb_prompt $" { > incr hwatch_count > + > + # Some targets (like S/390) behave as though supporting > + # unlimited hardware watchpoints. In this case we just take a > + # safe exit out of the loop. > + if { $hwatch_count == $NR_THREADS } { > + set done 1 > + break > + } > } > -re ".*Could not insert hardware watchpoint.*$gdb_prompt $" { > set done 1 > This looks good for me if the above is too tricky to implement. Thanks, Luis