This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Tracepoint support in Cygnus GDB ?
Date: Sun, 28 Sep 2003 10:13:38 -0400
From: Andrew Cagney <ac131313@redhat.com>
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
GNU/Linux.
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
GNU/Linux.
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
work.
> 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
above.
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.
Andrew