From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22089 invoked by alias); 8 Jan 2003 21:13:46 -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 22045 invoked from network); 8 Jan 2003 21:13:43 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 8 Jan 2003 21:13:43 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18WPOh-0000Vu-00; Wed, 08 Jan 2003 17:14:07 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18WNWI-0004mv-00; Wed, 08 Jan 2003 16:13:50 -0500 Date: Wed, 08 Jan 2003 21:13:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Mark Kettenis , gdb-patches@sources.redhat.com Subject: Re: [rfa/i386] Make codestream deprecated? Message-ID: <20030108211349.GA10113@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Mark Kettenis , gdb-patches@sources.redhat.com References: <3DEAAB57.4070609@redhat.com> <86bs3yoxc7.fsf@elgar.kettenis.dyndns.org> <3E1C878B.2050607@redhat.com> <20030108203021.GA5740@nevyn.them.org> <3E1C9225.8050605@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1C9225.8050605@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00340.txt.bz2 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. Sure, it takes time. Not all that much time, though; and it doesn't have to be done all at once. I prefer to remove it from one target at a time and then remove support for it entirely. There should be a reasonably close alternative available; after all, it's being deprecated in favor of something. > If you look through the change log you'll notice that deprecated methods > are being removed from the core of GDB, but the -tdep and -nat files are > being left largely untouched. Then, every so often, I or another > maintainer will expunge the deprecated code from a target being it back > into synck. Over time the old code moves to the edges of gdb where it > wilters and dies. I don't see this happening. I see it move to the edge of GDB where it withers, period. To come back to the case at hand, this construct has already "moved" (started out?) to the edge of GDB. Deprecating it isn't going to help it wither. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer