This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint support in Cygnus GDB ?
Date: Sun, 28 Sep 2003 18:23:40 -0400
From: Andrew Cagney <firstname.lastname@example.org>
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).
I think, at least in the case of GNU/Linux, this is inaccurate. We
are trying to catch up with the compiler, the library (glibc), and the
kernel (the system calls and innards that directly affect features
like threading and ptrace). My (perhaps inaccurate) impression is
that quite a few changes in GDB are due to the need to track those
fast moving targets.
For GLIBC and the Linux kernel [lets be rude :-] while they do suck a
certain percentage of resources, it's largly [and unfortunatly] due to
us needing to identify problems in the upstream code. The GDB changes
that are a direct consequence of the mods are actually minimal.
That leaves GCC and other compilers with their increasingly agressive
Even there, there is some good news. I believe that, in the past, the
single biggest maintenance headache was the prologue analyzer. With
CFI, that's largely stopped. Instead, provided the compiler is working
correctly, GDB can unwind any stack frame. Maintainers, and developers,
can get on with more interesting tasks such as adding new features :-)
Same goes for location expressions (once finished, its going to involve
more surgery, sigh).
As for GNU systems (such as GNU/Linux). If existing functionality
breaks, we'd better do something about it.
If the debugger knows less about the initimate details of a particular
OS, it is less likely to break when some central component of the OS
changes. I'm sure we are all aware of that, so it bewilders me why
should we argue about this trivial piece of knowledge.
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.
Andrew, you misunderstand me. I did not intend to publish some
criticism on the way you lead GDB development as opposed to what was
before. I'm just voicing my personal concerns about what I percieve
as a lack of significant progress, user-level feature-wise, in GDB
during the last years.
I'm not taking it that way :-) I'm trying to draw your attention to the
mistakes we as the GDB community allowed to happen in the past.
As a data point, consider the number of changes to the user manual:
the vast majority of changes didn't require any additions to the
manual. To me, it's a clear sign that most of the efforts do not
produce new features.
The apparent lack of new features is a reasonable concern.
The point I'm trying to make is that there is a very real reason for
this. GDB suffered [here we go, sob story :-)] from years of neglect.
The '90s were a period where new architectures and even some new
features were added, regardless of their level of completness or
maintenance cost. As maintainers we're now paying for those years of
Eli, here you're simply wrong. It requires a compatible toolchain
(binutils, elfutils). It does not require GNU/Linux.
On what systems, except on GNU/Linux, do we have such a toolchain
I think Daniel's explained this.
> 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
I suggested to point out specific goals, but not to tie them
dogmatically to specific releases.
That is reasonable. At present they are bug reports (category
change-request). I think Joel suggested a page to cross reference the
bug reports so that new features were easier to find.
Just keep in mind, and going back to my original concern, the emphasis
here must not be adding a new feature at all cost. The last thing this
group needs is for people to get an unrealistic expectation that their
jumbo feature patch is simply going to be committed . Instead its a
case of making the incremental changes needed so that the feature, in
the end, just slips in.
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.
I just hope that we don't lose the sight of the forest (user features)
for the trees, that's all.
Hmm, good analogy. In the past exactly that did happen. People kept
trying to cram more trees (architectures / features) into an already
overgrown forest. Think of the current work as thinning the trees so we
can once again see the entire forest.
To take this back to the original question (I should note that I speak
from experience here). In the deep dark past I wrote RDA (Red Hat's
debug agent). I then, later looked at _quickly_ grafting a sample
tracepoint implementation on top of it. I dropped it having figured out
the amount of work required. But did learn several things:
- rda's strongly OO target stack was "in the ballpark"
If GDB's going to get tracepoints, its target stack will need to be
changed to work in similar ways. There are a heap of reasons why GDB's
target stack needs an upgrade, this is one of them. Others include the
need to finish async.
- the very non-OO sample tracepoint code, was struggling.
It had a too direct and global a connection to both the architecture and
target. Having someone cleanroom the code is a realistic option.
- long term, gdbserver and gdb should merge
(I know daniel questions this :-) If the lower layers of the target
stack can be stripped back to something like rda/gdbserver then the
merge will be possible. By doing this we will have eliminated much
notable redundency in GDBs code, and in eliminating that redundency it
will be possible to add target based features just once.