This is the mail archive of the gdb@sources.redhat.com 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]

Features vs infrastructure (was Re: Tracepoint support in CygnusGDB ?)


Andrew Cagney wrote:


The apparent lack of new features is a reasonable concern.


The point I'm trying to make is that there is a very real reason for this. GDB suffered [here we go, sob story :-)] from years of neglect. The '90s were a period where new architectures and even some new features were added, regardless of their level of completness or maintenance cost. As maintainers we're now paying for those years of neglect.

Heh, I've been trolled! :-) I must say, I've been a little envious watching GDB development over the past couple of years; Cygnus was never able to afford so many cycles spent on internals. For multi-arch alone it took over three years from initial proposal to the actual hacking...


Just keep in mind, and going back to my original concern, the emphasis here must not be adding a new feature at all cost. The last thing this group needs is for people to get an unrealistic expectation that their jumbo feature patch is simply going to be committed . Instead its a case of making the incremental changes needed so that the feature, in the end, just slips in.

The downside of this approach is that if you discourage contributors too much up front, you'll never get those new features, cleanly implemented or otherwise. This is exactly the problem that Richard Kenner caused for GCC; he didn't want exception handling from the C++ folks because he was going to do a much better implementation, and they would use that. After years of waiting for him to actually do it, it turned out to be easier for the rest of the GCC hackers just to fork (thus EGCS). Now GDB today is not at all like pre-EGCS GCC, but some of the same tension is there.

It's a balancing act; you can't just hold off on new features until the
infrastructure is perfected, because it will always seem flawed in some
way.  At the same time entropy always increases, and new features make it
increase faster, so you need the infrastructure work to compensate.

I just thumbed through the GDB website and sources, and gdb/TODO seemed
like it was mostly a list of desired infrastructure changes.  For instance,
I didn't see a mention of the desirability of tracepoint support for native
debugging, although that is an obvious item for a wishlist.  Perhaps the
todo list should be separated into "user-visible" and "infrastructure"
sections, with appropriate xrefs, so that everybody is aware of what's
desired.

Stan




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