From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29867 invoked by alias); 1 Oct 2003 21:49:28 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29859 invoked from network); 1 Oct 2003 21:49:27 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sources.redhat.com with SMTP; 1 Oct 2003 21:49:27 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h91LnQvd010410 for ; Wed, 1 Oct 2003 14:49:27 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 1 Oct 2003 14:48:57 -0700 Received: from apple.com (vpn-scv-x3-113.apple.com [17.219.194.113]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h91LnEWI029501; Wed, 1 Oct 2003 14:49:14 -0700 (PDT) Message-ID: <3F7B4BEC.1060800@apple.com> Date: Wed, 01 Oct 2003 21:49:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Cagney CC: Eli Zaretskii , gdb@sources.redhat.com Subject: Features vs infrastructure (was Re: Tracepoint support in Cygnus GDB ?) References: <3F717475.33E13BC4@india.hp.com> <6654-Wed24Sep2003201904+0300-eliz@elta.co.il> <3F72FF8C.3080104@redhat.com> <6654-Sat27Sep2003132618+0300-eliz@elta.co.il> <3F75A491.4010203@redhat.com> <1659-Sat27Sep2003204134+0300-eliz@elta.co.il> <3F75D8D3.2090207@redhat.com> <2427-Sun28Sep2003102631+0300-eliz@elta.co.il> <3F76EC92.6010005@redhat.com> <4098-Sun28Sep2003234119+0300-eliz@elta.co.il> <3F775F6C.8070209@redhat.com> <3F784618.50203@redhat.com> In-Reply-To: <3F784618.50203@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00040.txt.bz2 Andrew Cagney wrote: > > The apparent lack of new features is a reasonable concern. > > The point I'm trying to make is that there is a very real reason for > this. GDB suffered [here we go, sob story :-)] from years of neglect. > The '90s were a period where new architectures and even some new > features were added, regardless of their level of completness or > maintenance cost. As maintainers we're now paying for those years of > neglect. Heh, I've been trolled! :-) I must say, I've been a little envious watching GDB development over the past couple of years; Cygnus was never able to afford so many cycles spent on internals. For multi-arch alone it took over three years from initial proposal to the actual hacking... > > Just keep in mind, and going back to my original concern, the emphasis > here must not be adding a new feature at all cost. The last thing > this group needs is for people to get an unrealistic expectation that > their jumbo feature patch is simply going to be committed . Instead > its a case of making the incremental changes needed so that the > feature, in the end, just slips in. The downside of this approach is that if you discourage contributors too much up front, you'll never get those new features, cleanly implemented or otherwise. This is exactly the problem that Richard Kenner caused for GCC; he didn't want exception handling from the C++ folks because he was going to do a much better implementation, and they would use that. After years of waiting for him to actually do it, it turned out to be easier for the rest of the GCC hackers just to fork (thus EGCS). Now GDB today is not at all like pre-EGCS GCC, but some of the same tension is there. It's a balancing act; you can't just hold off on new features until the infrastructure is perfected, because it will always seem flawed in some way. At the same time entropy always increases, and new features make it increase faster, so you need the infrastructure work to compensate. I just thumbed through the GDB website and sources, and gdb/TODO seemed like it was mostly a list of desired infrastructure changes. For instance, I didn't see a mention of the desirability of tracepoint support for native debugging, although that is an obvious item for a wishlist. Perhaps the todo list should be separated into "user-visible" and "infrastructure" sections, with appropriate xrefs, so that everybody is aware of what's desired. Stan