From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3000 invoked by alias); 11 Dec 2004 19:07:03 -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 2737 invoked from network); 11 Dec 2004 19:06:59 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sourceware.org with SMTP; 11 Dec 2004 19:06:59 -0000 Received: from zaretski (pns03-203-109.inter.net.il [80.230.203.109]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DXB93267 (AUTH halo1); Sat, 11 Dec 2004 21:06:05 +0200 (IST) Date: Sat, 11 Dec 2004 19:08:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c4dfb4$Blat.v2.2.2$a0ae47a0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: jjohnstn@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <20041211180236.GA16131@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 11 Dec 2004 13:02:36 -0500) Subject: Re: [RFA]: Modified Watchthreads Patch Reply-to: Eli Zaretskii References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <41BA00E1.20900@redhat.com> <20041210203729.GA7830@nevyn.them.org> <41BA168E.7030507@redhat.com> <41BA36C5.2030304@redhat.com> <01c4df75$Blat.v2.2.2$1a340140@zahav.net.il> <20041211165237.GC13865@nevyn.them.org> <01c4dfaa$Blat.v2.2.2$47bcb3c0@zahav.net.il> <20041211180236.GA16131@nevyn.them.org> X-SW-Source: 2004-12/txt/msg00316.txt.bz2 > Date: Sat, 11 Dec 2004 13:02:36 -0500 > From: Daniel Jacobowitz > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com > > > Another, even better (IMHO) rationale: one important reason for using > > watchpoints is to find what code accesses some specific data; when we > > use watchpoints for this, we more often than not do not know what > > thread will access the data. > > That's just a watchpoint without an explicit thread specified. That's > the default when you say "watch foo". Yes, but what is the difference between unexpected thread and any thread? In practice, it means you will need to stop on any thread, right? > > > Assuming that the program didn't stop for any other reason, and that > > > hardware watchpoints trigger after the write is executed > > > > (I note in parens that on x86, watchpoints trigger _before_ the write > > is executed. Not sure if it matters here.) > > How do we get the "new value" for a watchpoint, then? Do we step over > the instruction? Oops, sorry, I managed to completely confuse myself. You are right, watchpoints trigger after the data has been written. > This is "extending watchpoints to specific threads" in my > understanding, not to "threaded programs" Okay, I agree. But whetever the name, I think such an extension should be a useful one.