This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint support in Cygnus GDB ?
Date: Sat, 27 Sep 2003 14:37:07 -0400
From: Andrew Cagney <email@example.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
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
Keep in mind that GNU systems are a priority.
TLS and NPTL are native GNU/Linux only for reasons out side of GDB's
control. Tweaking TLS for other systems should be straight forward.
Follow fork isn't GNU/Linux specific (it originated in HP/UX) but does
need per-native target changes.
Separate debug info is very much an embedded feature - it lets embedded
distros make optional all the debug info for all those embedded C and
CFI and location expresions benefit all programmers and are a
significant new feature (but are not exactly user visible so lack the
"gee wiz" factor, which is why I didn't mention them).
From memory, the most recent embedded feature (related to watchpoints
and the target vector) stalled, the original patch need maintenance
work, and that hasn't yet happened.
> 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
How did we fail, exactly? What were the reasons for the failure?
Perhaps we could learn from past mistakes and do better next time?
The usual problems. Too many "must-have" features, and the few features
that people do work on running late.
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.
That is exactly what we did (the TODO file, 5.0) and, in the end, I
abandoned every single feature on that list. Many have since been
added, but not thanks to attempts to tie them to specific releases.
Having largely disconnected the release schedule from features, we're
doing much better. We make regular GDB updates that do contain new
features and, more importantly, fixes. At the same time people adding
features aren't pressured into bad shortcuts for the sake of an
unrealistic release schedule.
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.
I believe everyone here knows the #1 priority. Make:
(gdb) break main
(gdb) print foo
work. At present it doesn't. Breaking it down, "print foo" and "break
main" both require name spaces, "bt" requires improved frame code.
Things that are being actively worked on.