Re: Tracepoint support in Cygnus GDB ?

[Andrew Cagney <ac131313 at redhat dot com>]

> > 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.

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 
C++ libraries.

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 
> > 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?

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) run
(gdb) bt
(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.

Andrew