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: Sun, 28 Sep 2003 10:13:38 -0400
> From: Andrew Cagney <>
> Keep in mind that GNU systems are a priority.

I'm aware of that, but IMHO GDB development favors GNU/Linux too much.
And since the Linux kernel changes so frequently, the symbiotic
relationship between GDB and GNU/Linux tends to consume a lot of
resources, as we are shooting a moving target.

In other words, I'd be happier if a larger portion of GDB maintenance
resources were to go into more platform-independent features.

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

The facts are that these features are currently available only for

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

Still, it requires a feature in Binutils that only exists on

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

Exactly: this is not a user-level feature, but more like a bugfix.

> The usual problems.  Too many "must-have" features, and the few features 
> that people do work on running late.

Then let's have less must-have features next time.

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

Are you saying that there's no way we could set up practical goals for
GDB development?  I'd be surprised if you actually meant that, but
that's how it sounds.

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

As I said at the beginning of this discussion, I'm worried by the fact
that most of the recent GDB development effort is consumed by fixing
bugs and by building infrastructure, and very little goes into
user-level features.  So I applaud the progress being made in the
directions you describe, but I'd like to see our progress defined more
by user-level features, not only by bugfixes and infrastructure-related

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

Something that should work but doesn't is a bug.  So you again are
talking about fixing a bug; I don't see any user-level feature in the

> Breaking it down, "print foo" and "break 
> main" both require name spaces, "bt" requires improved frame code. 

That's infrastructure again.  While I understand the need for building
good infrastructure, I hope that infrastructure will be used for
adding user-level features, hopefully sooner rather than later.

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