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.

There's a certain irony here. People also complain that GDB favours embedded systems over GNU/Linux native systems; and spends too much time adding new architectures.

The symbiotic relationship is between GDB and the compiler; not GNU/Linux. It's the compiler that GDB's trying to keep pace with (well actually catch up).

As for GNU systems (such as GNU/Linux). If existing functionality breaks, we'd better do something about it.

TLS, for instance, is an ABI extension that is implemented by GCC (with a little bit of co-operation from the [linux] kernel and [g]libc). Non GNU/Linux systems will definitly pick up and exploit the feature!

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

This simply reflects the reality that most developers use GNU/Linux systems.

Unlike the past, the emphasis is on doing the internals in a portable way so that they do apply across all systems. This definitly wasn't the case when the original HP/UX only follow-fork implementation was committed.

The missing bit is an interest, by non GNU/Linux users, in getting the features added to their system.

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

Eli, here you're simply wrong. It requires a compatible toolchain (binutils, elfutils). It does not require GNU/Linux.

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.

I'm saying trying to tie specific features to specific releases is unrealistic.

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

The above is subtle.

Having it work correctly requires the constant addition of new features.

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.

Is the request to support debugging i386 binaries on x86-64 a bug, infrastructure, or a user visible feature? I'd argue its a feature, only, once working it just gives the user a better "break main; run" experience.

Is namespace support a bug, infrastructure, or a new feature. Again, I'd argue that its a new feature, but again at the end of the day it just improves "break main; run".

Is the lack of lazy breakpoints a bug, infrastructure or new feature (it's what every Java developer I know is asking for)? In the end, though, it too only results in a better "break main; run" experience so I guess its a bug.

The inability to set a breakpoint on inline functions? Bug? Infrastructure? Feature? Anyone using anything inline complains about that one.

I can't think of anyone here that is working on infrastructure for infrastructures sake (If I were doing that I'd be spending my time re-writing architecture specific code instead of deprecating / deleting them :-). The objective is new features. However, due to past neglect, we're now paying dearly spending more on cleanup and [arrrrg] finish up and less on user features.


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