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 18:23:40 -0400
From: Andrew Cagney <>

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

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

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

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.


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