From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27227 invoked by alias); 10 Dec 2004 20:37:38 -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 27203 invoked from network); 10 Dec 2004 20:37:34 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 10 Dec 2004 20:37:34 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CcrW5-00027d-Mt; Fri, 10 Dec 2004 15:37:29 -0500 Date: Fri, 10 Dec 2004 20:47:00 -0000 From: Daniel Jacobowitz To: Jeff Johnston Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: Modified Watchthreads Patch Message-ID: <20041210203729.GA7830@nevyn.them.org> Mail-Followup-To: Jeff Johnston , gdb-patches@sources.redhat.com References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <41BA00E1.20900@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41BA00E1.20900@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00275.txt.bz2 On Fri, Dec 10, 2004 at 03:02:41PM -0500, Jeff Johnston wrote: > >On the technical side, two questions: > > > >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? > > > > Actually, with i386/x86-64 I discovered that the debug registers are global > in scope for the setting of watchpoints (i.e. I didn't have to use the > observer). The status register, however, is thread-specific for reporting > them. I have gotten the watchthreads.exp testcase working for both > platforms. Your lwp fix helps a lot with this. We call TIDGET()/PIDGET() > in the low-level code which used to get called in the wrong ptid mode so we > kept checking the main-thread for the watchpoint. Er... do you know why the debug registers are global, and what kernel is this with? They look thread-specific to me (kernel 2.6.10-rc1). They are accessible using PEEKUSR/POKEUSR for each thread, and __switch_to updates them at context switches. > >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. > > > > It works fine for the watchthreads.exp test once all the mechanisms are in > place (I have a few more patches to go). We don't want to iterate over all > threads unless we know the platform has a problem. Otherwise, we won't be > able to pin down a specific watchpoint triggered with the thread/source > line that triggered it. Is there a valid scenario where inferior_ptid > should not be the thread for the signal chosen by the low-level linux-nat > code? If not, I would prefer to treat that as a bug that requires pinning > down. We can delay this issue, then. I am concerned about losing watchpoints when other events are active, e.g. a thread event breakpoint or dlopen breakpoint and a read watchpoint. I'm sure GDB gets this wrong already. Please fix the whitespace at the end of s390-nat.c. Otherwise, this is approved if Ulrich is OK with the S390 bits; let's give him a chance to comment. -- Daniel Jacobowitz