This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tracepoint support in Cygnus GDB ?

Date: Sat, 27 Sep 2003 14:37:07 -0400
From: Andrew Cagney <>

> 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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]