From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20106 invoked by alias); 9 Nov 2004 19:31:33 -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 20052 invoked from network); 9 Nov 2004 19:31:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 Nov 2004 19:31:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CRbi8-0001IV-C8; Tue, 09 Nov 2004 14:31:24 -0500 Date: Tue, 09 Nov 2004 19:31:00 -0000 From: Daniel Jacobowitz To: Jeff Johnston Cc: Andrew Cagney , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Watchpoints per thread patch Message-ID: <20041109193124.GA4085@nevyn.them.org> Mail-Followup-To: Jeff Johnston , Andrew Cagney , Eli Zaretskii , gdb-patches@sources.redhat.com References: <01c4bca9$Blat.v2.2.2$adcffb00@zahav.net.il> <418A741C.4080306@redhat.com> <20041105044917.GA13554@nevyn.them.org> <418BAFC9.6050705@gnu.org> <20041105182850.GA22533@nevyn.them.org> <418FE5E7.3070501@gnu.org> <20041109010425.GA31431@nevyn.them.org> <4190292D.5070103@gnu.org> <20041109023306.GA1797@nevyn.them.org> <4191151F.6070607@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4191151F.6070607@redhat.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00173.txt.bz2 On Tue, Nov 09, 2004 at 02:06:07PM -0500, Jeff Johnston wrote: > Time out here for a second. I have been modifying this patch according to > "your" comments. I have had a design that had no observers and one that > kept the observation isolated to the linux code. The design without observers had plenty of other problems, e.g. it also broke remote debugging. My suggestion about putting the observer in add_thread was a bad one. I've never claimed to be an infallible lord of development. A new_thread observer does indeed belong in add_thread, but is not suitable for your use; and I didn't understand why until later. We could use a Linux native specific observer, or handle this through the target stack. I think handling it through the target stack makes more sense, but I haven't sketched out what the target method would look like. If other GDB developers think that the precedent of a native-code-only observer isn't a bad one, then maybe we should go back to your previous placement of the observer and give it a Linux specific name. This will be aided by renaming thread-db to be clearly Linux native code. > One key issue of my latest patch you seem to object to is the fact that I > now have to massage the ptid. This was not necessary in the previous > design where I was observing within the linux code where the lwp was > readily available. We both know the low-level code is fundamentally wrong > in its assumption regarding the ptids. They cannot be assumed to be in > PID, LWP, 0 format. We get lucky with register accesses only because the > thread-db code is flushing registers in the lwp format. It is not > documented and when low-level code accesses ptids outside of thread-db, it > is wrong. Watchpoints are in the this boat because they are accessed by > breakpoint.c and infrun.c where the ptid is in the wrong format (PID, 0, > TID). > > I feel your objection to temporarily massaging these ptids as thread-db.c > does is unreasonable. We need to think of the end-user. The amount of > code added is small and it is trivial to remove this code once the > preferred solution is in place. There is currently no work-around to > solving thread bugs involving memory corruption. > > If you have a fix planned soon regarding the ptid format, I have absolutely > no objection to waiting for it. However, if you can't get around to this > for a while due to other commitments or it is going to take some hashing > out on the list, let's stop punishing the end-user and do something helpful > while we work things out proper. Jeff, I've already posted the thread-db change to make this unnecessary. I was asked to rename the file first, and I've posted that too. -- Daniel Jacobowitz