This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Features vs infrastructure (was Re: Tracepoint support in CygnusGDB ?)
- From: Stan Shebs <shebs at apple dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Eli Zaretskii <eliz at elta dot co dot il>, gdb at sources dot redhat dot com
- Date: Wed, 01 Oct 2003 14:49:32 -0700
- Subject: Features vs infrastructure (was Re: Tracepoint support in CygnusGDB ?)
- References: <3F717475.33E13BC4@india.hp.com> <6654-Wed24Sep2003201904+0300-eliz@elta.co.il> <vt2he31olrj.fsf@zenia.home> <3F72FF8C.3080104@redhat.com> <6654-Sat27Sep2003132618+0300-eliz@elta.co.il> <3F75A491.4010203@redhat.com> <1659-Sat27Sep2003204134+0300-eliz@elta.co.il> <3F75D8D3.2090207@redhat.com> <2427-Sun28Sep2003102631+0300-eliz@elta.co.il> <3F76EC92.6010005@redhat.com> <4098-Sun28Sep2003234119+0300-eliz@elta.co.il> <3F775F6C.8070209@redhat.com> <uzngogl7s.fsf@elta.co.il> <3F784618.50203@redhat.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