From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9154 invoked by alias); 16 Jun 2004 21:39:31 -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 9145 invoked from network); 16 Jun 2004 21:39:29 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 16 Jun 2004 21:39:29 -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 i5GLdTe1021684 for ; Wed, 16 Jun 2004 17:39:29 -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 i5GLdT023602; Wed, 16 Jun 2004 17:39:29 -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 i5GLdStn004632; Wed, 16 Jun 2004 17:39:29 -0400 Received: from tooth.toronto.redhat.com (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id C392E800326; Wed, 16 Jun 2004 17:39:28 -0400 (EDT) Date: Wed, 16 Jun 2004 21:39:00 -0000 From: jjohnstn X-X-Sender: jjohnstn@tooth.toronto.redhat.com To: Ulrich Weigand Cc: gdb-patches@sources.redhat.com, Subject: Re: [RFC]: x86 threaded watchpoint support [2/3] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-06/txt/msg00391.txt.bz2 On Tue, 15 Jun 2004, Ulrich Weigand wrote: > > > > > Jeff Johnston wrote: > > >The change is needed because with the threading model, you can have > >multiple events to process. So, if you check your watchpoint values, > >all of them may have changed but you end up reporting an invalid thread > >location. For example, I was getting watchpoints changing at the same > >time of a new thread event (it couldn't discern). > > Isn't it enough to know whether you got the SIGTRAP because of a (any) > hardware watchpoint, or for some other reason (e.g. new thread event)? > > *This* information is available on s390, and as of this patch: > http://sources.redhat.com/ml/gdb-patches/2004-05/msg00290.html > it is actually used to prevent bpstat_stop_status to recognize > a watchpoint event unless the kernel says it was a watchpoint ... > 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. > Do you have more details about n what situation is this still not > enough? > Knowing at least one watchpoint triggered is not enough detail. Gdb then has to check all values for change. We may not stop all threads until multiple watchpoints change. Now, imagine you have 1000 threads. Even if we get one thread correct, the end-user has to do an info threads and search the other 999 threads to figure out where the other values got changed. I personally use a watchpoint when I know a value has changed but can't figure out why it changed or there is some particular transition of value I am interested in. In some cases, gdb won't be able to tie the thread to the watchpoint but where we can do so, we definitely should. -- Jeff J. > > Mit freundlichen Gruessen / Best Regards > > Ulrich Weigand > > -- > Dr. Ulrich Weigand > Linux for S/390 Design & Development > IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen > Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com > >