From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20604 invoked by alias); 21 Jun 2004 19:57:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20596 invoked from network); 21 Jun 2004 19:57:57 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 21 Jun 2004 19:57:57 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5LJvue1016072 for ; Mon, 21 Jun 2004 15:57:56 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5LJvs018152; Mon, 21 Jun 2004 15:57:55 -0400 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id i5LJvrtn001373; Mon, 21 Jun 2004 15:57:53 -0400 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id DCBD88003A5; Mon, 21 Jun 2004 15:57:52 -0400 (EDT) Message-ID: <40D73DC0.5090601@redhat.com> Date: Mon, 21 Jun 2004 19:57:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com, uweigand@de.ibm.com Subject: Re: [RFA]: Fix for watchpoint regressions References: <40D7016F.1070406@redhat.com> <2719-Mon21Jun2004220328+0300-eliz@gnu.org> In-Reply-To: <2719-Mon21Jun2004220328+0300-eliz@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00484.txt.bz2 Eli Zaretskii wrote: >>Date: Mon, 21 Jun 2004 11:40:31 -0400 >>From: Jeff Johnston >> >>2004-06-18 Jeff Johnston >> >> * infrun.c (handle_inferior_event): Initialize stopped_by_watchpoint >> to -1. >> * breakpoint.c (bpstat_stop_status): Move check for ignoring >> untriggered watchpoints to a separate if clause. Update function >> comment regarding STOPPED_BY_WATCHPOINT argument. > > > Won't this break the cases that caused the addition of testing that > stopped_by_watchpoint is non-zero in bpstat_stop_status? > I took care to try to ensure that the problem the original patch was fixing was still being addressed. The stopped_by_watchpoint flag was only being set by handle_inferior_event if HAVE_CONTINUABLE_WATCHPOINT is true. In the cases where the flag should be tested, it will be set correctly to false (0) or true (1). The problem is that there is third state (don't know) which is due to the fact that the flag is not set in certain cases and you don't really know if you are stopped by a watchpoint or not. This occurs, for example, when HAVE_NONSTEPPABLE_WATCHPOINT or HAVE_STEPPABLE_WATCHPOINT is true as in the case of ia64. The flags indicate that the watchpoint has triggered prior to the actual change or value. The handle_inferior_event function steps through the watchpoint change. At that point, the STOPPED_BY_WATCHPOINT test doesn't return true for ia64, were it to be tested. My original attempt at this was to try and set the flag regardless of the HAVE_CONTINUABLE_WATCHPOINT. It did not work because STOPPED_BY_WATCHPOINT is not true after the step. Things worked in the past for ia64 because the code near the bottom of the loop in bpstat_stop_status would check whether a hardware watchpoint value had changed. With Ulrich's original patch in place, this never happens because we never get to that piece of code in the loop. With the revised patch, for the original scenario that Ulrich was fixing, we will not get to the watchpoint checking code, but for platforms that do not have HAVE_CONTINUABLE_WATCHPOINT, we will. We won't yet be able to handle the breakpoint insn in code scenario for ia64 that Ulrich was fixing, but that is a separate fix. I am looking at making another patch which would mark a watchpoint for the stepping cases so we can tell if a particular watchpoint triggered or not prior to the step and thus allow gdb to avoid having to randomly test all value changes. This would help to eliminate the cases where we might report n different watchpoint changes for a line of code where the code in question may only be responsible for one of the value changes. This would also allow the breakpoint insn in code scenario to work on ia64. -- Jeff J.