This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa/i386] Make codestream deprecated?

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]