From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14851 invoked by alias); 11 Dec 2004 16:52:46 -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 14802 invoked from network); 11 Dec 2004 16:52:42 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Dec 2004 16:52:42 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CdAU1-0003qj-5g; Sat, 11 Dec 2004 11:52:37 -0500 Date: Sat, 11 Dec 2004 16:56:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Jeff Johnston , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Modified Watchthreads Patch Message-ID: <20041211165237.GC13865@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Jeff Johnston , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4df75$Blat.v2.2.2$1a340140@zahav.net.il> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00303.txt.bz2 On Sat, Dec 11, 2004 at 01:31:29PM +0200, Eli Zaretskii wrote: > > Date: Fri, 10 Dec 2004 18:52:37 -0500 > > From: Jeff Johnston > > Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com [A lot of stuff I completely agree with deleted.] > > As I observed before, the actual watchpoint only needs to be set on > > one thread and it will trigger in other threads. > > One issue we should discuss is do we really want this behavior? Do we > really want GDB to stop the inferior when another thread hits the > watchpoint that we set in a specific thread, or do we want a > watchpoint to break only in the thread in which it was set? There are > valid arguments for both alternatives, and we never came to any > resolution of this issue, since back when it was discussed, the state > of support in GDB for multi-threaded programs was in flux. Here's a proposal; I'm thinking it out as I write it, so if you can break it you get to keep all the shiny pieces. - The GDB core needs to continue to support watchpoints (hardware breakpoints; et cetera) triggering in an unexpected thread. Rationale: some targets won't support any other way. For instance page protection based watchpoints on GNU/Linux would probably apply to all threads. - As an optimization, the interfaces for inserting and removing watchpoints could specify a thread to apply the watchpoint to. The target could, if it supports this operation, apply the watchpoint to only that thread. How useful would this be? For hardware read or write watchpoints, very. For "normal" hardware watchpoints (bp_hardware_watchpoint), I think almost not at all. GDB relies on knowing the value of all watched locations to decide whether the watchpoint "triggered" and should stop the program, right? If other threads modify the watched location, GDB would report the watchpoint the next time we stop, because the value would appear to change. And consider a scenario like this: Thread A Thread B *p = 0 *p = 1 *p = 0 *p = 1 *p = 0 *p = 1 *p = 0 Assuming that the program didn't stop for any other reason, and that hardware watchpoints trigger after the write is executed, "watch *p thread A" would never trigger, because the value would always appear to be the same. This fails my usual spot-check for a useful user interface design, because it is difficult to explain or justify it without resorting to an explanation of the implementation's limitations. If we want thread-specific watchpoint insertion, I think that we need to either restrict it to rwatch/awatch, or come up with a more useful behavior for software and hardware watchpoints than the one I've thought of. Can you think of one? -- Daniel Jacobowitz