From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32384 invoked by alias); 27 Sep 2003 18:37:26 -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 32374 invoked from network); 27 Sep 2003 18:37:24 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 27 Sep 2003 18:37:24 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A3A772B89; Sat, 27 Sep 2003 14:37:07 -0400 (EDT) Message-ID: <3F75D8D3.2090207@redhat.com> Date: Sat, 27 Sep 2003 18:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii Cc: pes@india.hp.com, jimb@redhat.com, gdb@sources.redhat.com Subject: 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00340.txt.bz2 > > Still, it's disturbing, to put it mildly, that I hadn't seen any > significant new features in a long while. That isn't correct. GDB 6.0 does contain a significant number of user visible features: hosted file I/O (which is embedded), TLS, NPTL, separate debug info (which will help embedded), useable java, follow fork, ... On the horizon are Ada, gcov/gprof, strace, ... What is missing is the good old days [sarcasm] of the eye catching glamor jumbo patch - incomplete hacks that were piled, one by one by one, on top of GDB until it nearly collapsed. While we're still digging ourselves out of that one, much progress has been made. > Perhaps we should decide on > a list of new features that the next release should have, and start > working on them. We've tried that, most recently with 6.0 and some MI features, and failed. As a group we found it necessary to largely disconnect release cycles from feature cycles. Instead releases based are based more on the calendar (yes this one is badly late) than some arbitrary feature list. enjoy, Andrew