From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19579 invoked by alias); 9 Nov 2004 02:33:24 -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 19505 invoked from network); 9 Nov 2004 02:33:11 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 Nov 2004 02:33:11 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CRLog-0000WB-I6; Mon, 08 Nov 2004 21:33:06 -0500 Date: Tue, 09 Nov 2004 02:33:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jeff Johnston , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Watchpoints per thread patch Message-ID: <20041109023306.GA1797@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jeff Johnston , Eli Zaretskii , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4190292D.5070103@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00146.txt.bz2 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! -- Daniel Jacobowitz