From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31902 invoked by alias); 10 Dec 2004 23:52:50 -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 31454 invoked from network); 10 Dec 2004 23:52:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 10 Dec 2004 23:52:40 -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 iBANqeLp008051 for ; Fri, 10 Dec 2004 18:52:40 -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 iBANqdr24700; Fri, 10 Dec 2004 18:52:39 -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 iBANqboS014891; Fri, 10 Dec 2004 18:52:37 -0500 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 8A7828002A2; Fri, 10 Dec 2004 18:52:37 -0500 (EST) Message-ID: <41BA36C5.2030304@redhat.com> Date: Fri, 10 Dec 2004 23:57: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: Jeff Johnston Cc: Daniel Jacobowitz , 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> <41BA168E.7030507@redhat.com> In-Reply-To: <41BA168E.7030507@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00286.txt.bz2 Jeff Johnston wrote: > 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. > Interesting results. Applying my previous patch and just changing the FIXME code in dr_get_register and dr_set_register to use the standard: tid = TIDGET (inferior_ptid); if (tid == 0) tid = PIDGET (inferior_ptid); allows watchthreads.exp to work for both x86 and x86_64. For x86, I used an fc3 system with a 2.6.9-1.667smp kernel. I had to use an RHEL3 2.4 kernel for x86-64. The test sets two watchpoints that will be triggered once in the main thread and thereafter in two distinct threads. The test verifies that each value is incremented as it should in the correct thread. It makes sure there are no missing jumps. I have witnessed multiple watchpoint events and thread creation events requiring processing at the same time (i.e. deferred events required) and it handles these correctly. I tried an experiment and broke in the thread function in one of the threads. I then watched a variable that can only be triggered in a separate thread. That also worked which was cool. As I observed before, the actual watchpoint only needs to be set on one thread and it will trigger in other threads. I can send you the additional patch if you want to experiment with it. I am still waiting for a machine with the latest RH kernel on it. I'll let you know if that works the same. -- Jeff J.