This is the mail archive of the
mailing list for the GDB project.
Re: [rfa/i386] Make codestream deprecated?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Mark Kettenis <kettenis at chello dot nl>, gdb-patches at sources dot redhat dot com
- Date: Wed, 8 Jan 2003 16:13:50 -0500
- Subject: Re: [rfa/i386] Make codestream deprecated?
- References: <3DEAAB57.email@example.com> <firstname.lastname@example.org> <3E1C878B.email@example.com> <20030108203021.GA5740@nevyn.them.org> <3E1C9225.firstname.lastname@example.org>
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
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
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
MontaVista Software Debian GNU/Linux Developer