From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9340 invoked by alias); 17 Jun 2004 19:47:02 -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 9320 invoked from network); 17 Jun 2004 19:47:01 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 17 Jun 2004 19:47:01 -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 i5HJl1e1023143 for ; Thu, 17 Jun 2004 15:47:01 -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 i5HJl1025416; Thu, 17 Jun 2004 15:47:01 -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 i5HJl0tn015217; Thu, 17 Jun 2004 15:47:00 -0400 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 2DC2380032B; Thu, 17 Jun 2004 15:47:00 -0400 (EDT) Message-ID: <40D1F534.3080802@redhat.com> Date: Thu, 17 Jun 2004 19:47: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: Ulrich.Weigand@de.ibm.com, gdb-patches@sources.redhat.com Subject: Re: [RFC]: x86 threaded watchpoint support [2/3] References: <7494-Thu17Jun2004072027+0300-eliz@gnu.org> In-Reply-To: <7494-Thu17Jun2004072027+0300-eliz@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00418.txt.bz2 Eli Zaretskii wrote: >>Date: Wed, 16 Jun 2004 17:39:28 -0400 (EDT) >>From: jjohnstn >> >>Actually, I believe this patch needs to be reworked. It is causing a >>failure for ia64 watchpoints. There are a number of problems to be looked >>at. First of all, the stopped_by_watchpoint flag only gets set if >>HAVE_CONTINUABLE_WATCHPOINT is true. Thus, any platform that doesn't >>define this macro or have the low level target >>to_have_continuable_watchpoint value set, will never set the >>stopped_by_watchpoint flag. The logic in >>bpstat_stop_status ignores all hardware watchpoints if the flag is not set >>so we never do the value comparison. >> >>Another problem is that some watchpoints are stepped (i.e. the signal >>occurs before the value is actually changed). When we step over the >>watchpoint, again the flag won't get set because we have actually trapped >>due to a step operation, not a watchpoint. > > > Can you suggest a patch to take care of these problems? > I intend to. I just wanted to point out that patch is causing a number of problems people are seeing. I have to first respond to a myriad of comments to other patches of mine. > >>Knowing at least one watchpoint triggered is not enough detail. Gdb then >>has to check all values for change. > > > If all the platform does is tell us that _some_ watchpoint breaks, > what else can we do? > You cut out my later sentence which translated to: "if gdb can get the information, it should do so, otherwise it will have to do its best". > >>We may not stop all threads until multiple watchpoints change. > > > This should produce several more SIGTRAPs, one each for every > watchpoint that triggers in between. Can we somehow find out there > are several more SIGTRAPs pending, and what threads have them pending? > > If not, I again don't see how can GDB do better in this situation. > Sounds like some help from the kernel is in order. > In some cases, the best gdb will be able to do is check all watchpoints and print out all values that have changed. Yes, some kernel changes could help in these situations. -- Jeff J.