From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28806 invoked by alias); 10 Dec 2004 23:06:18 -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 28742 invoked from network); 10 Dec 2004 23:06:09 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 10 Dec 2004 23:06:09 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Cctpr-00067B-SY; Fri, 10 Dec 2004 18:06:03 -0500 Date: Fri, 10 Dec 2004 23:10:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA]: Modified Watchthreads Patch Message-ID: <20041210230603.GA23419@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , jjohnstn@redhat.com, gdb-patches@sources.redhat.com References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <01c4df0c$Blat.v2.2.2$244dda20@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4df0c$Blat.v2.2.2$244dda20@zahav.net.il> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00282.txt.bz2 On Sat, Dec 11, 2004 at 01:00:08AM +0200, Eli Zaretskii wrote: > > Date: Fri, 10 Dec 2004 14:10:15 -0500 > > From: Daniel Jacobowitz > > Cc: gdb-patches@sources.redhat.com > > > > 1) I can see that it will be a bit of work to rearrange i386-linux to > > use this, but it should be doable. Do you know offhand of any > > i386-specific problems other than inserting watchpoints for all > > threads? > > The design of the x86 watchpoint support explicitly assumes that > watchpoints are not thread-local. If we want to lift that limitation, > I think the x86-specific code needs to be redesigned. Someone who > knows way more than I do about x86 threads and how the debug registers > are handled by the relevant kernels in the presence of threads, should > present a clean replacement design that deals with thread-local > watchpoints. Small modifications like inserting watchpoints for all > threads and other similar patchwork will simply not cut it, IMHO. Does the i386 native watchpoint support work on any existing target with multiple threads? I think this is a more accurate description of the assumptions, even though it's from i386-linux-nat.c: /* FIXME: kettenis/2001-01-29: It's not clear what we should do with multi-threaded processes here. For now, pretend there is just one thread. */ > Observe: > > > 2) What should to_stopped_by_watchpoint do in the presence of multiple > > threads? It looks like it relies on inferior_ptid being the thread > > which stopped at a watchpoint; I'm worried that that may not be > > consistently true in a heavily threaded application. Maybe it should > > iterate over all threads. > > > > The to_stopped_data_address has its own problems with threads; but the > > case of handling hitting two watchpoints at once, I think, we can leave > > for another day. > > These two are just the tip of the iceberg, but already you discovered > that the two cornerstones of the GDB watchpoint support do not work > reliably in multithreaded programs. We should redesign the x86 > watchpoint support instead of taking the evolutionary approach, which > will leave us with messy, unmaintainable, and buggy code. That is not a problem with the i386 native support for watchpoints; it is a problem with the core GDB interfaces for watchpoints, a much bigger problem. If you don't think we can support multi-threaded watchpoints in GDB without doing this redesign first, do you object to Jeff's current patch? To get a useful level of support from the i386 watchpoint code, in fact, looks pretty easy. Most of it would be local to the existing low-level support routines which are implemented in an i386-linux specific file. I can't say any more than that, since Jeff hasn't posted his patch yet. -- Daniel Jacobowitz