From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27773 invoked by alias); 9 Nov 2004 19:06:20 -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 27596 invoked from network); 9 Nov 2004 19:06:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Nov 2004 19:06:08 -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 iA9J68Vi011358 for ; Tue, 9 Nov 2004 14:06:08 -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 iA9J68r03055; Tue, 9 Nov 2004 14:06:08 -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 iA9J67oS028460; Tue, 9 Nov 2004 14:06:08 -0500 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id CF1CB80035F; Tue, 9 Nov 2004 14:06:07 -0500 (EST) Message-ID: <4191151F.6070607@redhat.com> Date: Tue, 09 Nov 2004 19:06: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: Andrew Cagney , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Watchpoints per thread patch References: <20041020173035.GA26622@nevyn.them.org> <418022DE.204@redhat.com> <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> In-Reply-To: <20041109023306.GA1797@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00169.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Nov 08, 2004 at 09:19:25PM -0500, Andrew Cagney wrote: > >>Daniel Jacobowitz wrote: >> >>>On Mon, Nov 08, 2004 at 04:32:23PM -0500, Andrew Cagney wrote: >>> >>> >>>>Given our already overcommitted backlog: breakpoints on C++ >>>>constructors, breakpoints on inline code, DW_OP_piece, i18n, multi-arch >>>>solib, ....; how realistic is it that we'll, in addition, manage to both >>>>refactor the linux code base (I know this will be slow as I've been >>>>working on it) and also add multi-threaded watchpoints, all in the 6.4 >>>>time frame? >>>> >>>>Let concentrate on clearing existing backlog, and not add another >>>>promise to the list. >>> >>> >>>*sarcasm* >>> >>>You're right. That's an excellent plan. Let's just drop the >>>multithreaded watchpoint patch, then, if it will never make it >>>to the front of the backlog. >> >>>*sarcasm off* >> >>Looks like I touched a raw nerve, eh? >> >>Well let me touch another one. Ask any serious developer trying to use >>GDB and they'll tell you bluntly ``we sux'', and the things I listed >>(along with multi-threaded watchpoints) are why ``we sux''. >> >>Can we sux a lttle less and at least support multi-threaded watchpoints? > > > Yes, you touched a raw nerve. You touched a raw nerve where you are > attempting to hold contributions from different contributors to > different standards. For instance, you blocked vsyscall support for > months because you objected to the quality and design of the code; I > felt it was of satisfactory quality, but you and I already know that we > disagree about many aspects of software design. > > I think that Jeff's patch, with your suggested kludge, is of much worse > quality than that was. It's a gross hack around a mechanism that has > enough existing problems. I do not want it added to GDB, whose average > quality level is quite bad enough already. > > >>The obvious solution here is to accept a simplified version of the >>patch, as that way we at least get the feature into 6.4. > > > Not at all. The obvious solution is the same solution we've used > before: for a developer who cares about this feature to put their > attention on the necessary cleanups. I've already volunteered to > resolve the problem of finding the LWP ID for Jeff. Even if it takes me > a while it'll be plenty of time before 6.4. You're already working on > the GNU/Linux native target vector cleanup; I'll help. If we want to > make GDB into _less_ of a pile of crap then adding _more_ crap code to > it is not the right way to do it! > 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. 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 J.