From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2161 invoked by alias); 8 Jan 2003 22:43:13 -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 2113 invoked from network); 8 Jan 2003 22:43:10 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by 209.249.29.67 with SMTP; 8 Jan 2003 22:43:10 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 27A033EC2; Wed, 8 Jan 2003 17:43:01 -0500 (EST) Message-ID: <3E1CA974.6070807@redhat.com> Date: Wed, 08 Jan 2003 22:43:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [rfa/i386] Make codestream deprecated? References: <3DEAAB57.4070609@redhat.com> <86bs3yoxc7.fsf@elgar.kettenis.dyndns.org> <3E1C878B.2050607@redhat.com> <20030108203021.GA5740@nevyn.them.org> <3E1C9225.8050605@redhat.com> <20030108211349.GA10113@nevyn.them.org> <20030108211935.GA22170@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00346.txt.bz2 > On Wed, Jan 08, 2003 at 04:13:50PM -0500, Daniel Jacobowitz wrote: > >> On Wed, Jan 08, 2003 at 04:03:33PM -0500, Andrew Cagney wrote: > >> > > >> > >Besides: this is why you should _remove_ them, rather than just >> > >commenting them, if you want them to go away. > >> > >> > The implication here being that I'm not removing deprecated code? > >> >> A heck of a lot slower than you're deprecating! There are now over >> 1200 references to deprecated constructs in GDB. That's just a rough >> estimate, mind. >> >> I understand why release branches are bad points to compare against for >> this, but since I have several handy: >> ~150 deprecated references in gdb 5.3 >> ~30 in gdb 5.2 >> > >> > The simple reality is that it is not possible for a single individual >> > remove all the old code in a single hit. It takes a group of people >> > co-operating, and it takes time. > > > I feel the need to add: > > If you are deprecating things single-handedly, what group of people do > you expect to co-operate? It's a matter of cleaning up after yourself. No one is trying to do anything single handedly. I'm just the luck one that gets to follow through some of the dirty work (and put up with the resultant flack :-). Since 5.3 branched, several major changes have gone down, and one is still in progress: - the complaint mechanism was replaced. Kevin did the bulk of the work here and in the process fixed a significant number of bugs! - the register cache was rewritten Probably the single biggest nasty bit of work - registers[] - is no longer relevant. The core code no longer uses it. People are slowly expunging -tdep and -nat code of the remainging references. - the frame's 15 year service Cleanly integrating things like cfi-frame is made possible; sillyness such as re-analyzing a prolog N times can be stopped; the posability of having more than one active frame chain (one per thread, hint, hint) is real. The immedate focus is obviously on finishing the new code so that that doesn't end up going the same way as many other half finished GDB projects (gdb, you'll have to agree, already has too many of these). To that very end, I've finished making `struct frame_info' opaque and I can start changing its internals. However, like others (including you) I also spend time expunging deprecated methods. enjoy, Andrew