This is the mail archive of the
mailing list for the GDB project.
Re: [rfa/i386] Make codestream deprecated?
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 :-).
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
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.
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
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