This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Tracepoint support in Cygnus GDB ?
> Date: Sat, 27 Sep 2003 14:37:07 -0400
> From: Andrew Cagney <ac131313@redhat.com>
>
> > Still, it's disturbing, to put it mildly, that I hadn't seen any
> > significant new features in a long while.
>
> That isn't correct. GDB 6.0 does contain a significant number of user
> visible features: hosted file I/O (which is embedded), TLS, NPTL,
> separate debug info (which will help embedded), useable java, follow
> fork, ...
Sorry, this doesn't refute what I said: TLS, NPTL, separate debug
info, and follow-fork features work on GNU/Linux only. Hosted I/O is
only useful for embedded targets, and Java is only useful for Java
programmers.
I did say in my original message that GNU/Linux was an exception: most
of the new features work only on that system. Your list supports what
I said.
What I was after was significant new features for native debugging
that would work not only on GNU/Linux, and not only for some specific
programming language.
If the main maintenance effort until now was supposed to make addition
of such features easier, then I applaud that effort and am sympathetic
to it, but I still am impatient to see the features themselves.
> > Perhaps we should decide on
> > a list of new features that the next release should have, and start
> > working on them.
>
> We've tried that, most recently with 6.0 and some MI features, and
> failed.
How did we fail, exactly? What were the reasons for the failure?
Perhaps we could learn from past mistakes and do better next time?
> As a group we found it necessary to largely disconnect release
> cycles from feature cycles. Instead releases based are based more on
> the calendar (yes this one is badly late) than some arbitrary feature list.
These two goals not necessarily contradict. We could set up a list of
features that are to be included in the next release, and if some of
the features are not ready in time, make a release without them.
IMHO, having a relatively short list of user-level features that are
first priority would be a good aid for maintainers, in setting their
priority to review patches, if for nothing else.