From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4051 invoked by alias); 10 Dec 2004 21:35:22 -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 4027 invoked from network); 10 Dec 2004 21:35:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 10 Dec 2004 21:35:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iBALZBRc006198 for ; Fri, 10 Dec 2004 16:35:16 -0500 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 iBALZAr22385; Fri, 10 Dec 2004 16:35:10 -0500 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 iBALZAoS010149; Fri, 10 Dec 2004 16:35:10 -0500 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 4D86F8002A2; Fri, 10 Dec 2004 16:35:10 -0500 (EST) Message-ID: <41BA168E.7030507@redhat.com> Date: Fri, 10 Dec 2004 22:18:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA]: Modified Watchthreads Patch References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <41BA00E1.20900@redhat.com> <20041210203729.GA7830@nevyn.them.org> In-Reply-To: <20041210203729.GA7830@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00277.txt.bz2 Daniel Jacobowitz wrote: > 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. > I am simply speaking from experience with the RHEL3 kernel. I got it working without touching the insert/remove logic. I am currently retrofitting new changes into the mainline gdb that are much "cleaner" than my previous fixes. I haven't tried x86 on the latest kernel, but I am in the midst of putting together an uber-patch with the stuff here plus some other things needed for each platform. IA64 is already finished and running watchthreads.exp on a next-release kernel. I am about to start x86 so I will keep in mind your comment. I'll let you know either way what I had to do to get it working. > >>>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. > Great. Will make the white-space change and wait for Ulrich. -- Jeff J.