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

[Stan Shebs <shebs@apple.com>]

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