Re: Tracepoint support in Cygnus GDB ?

[Andrew Cagney <ac131313@redhat.com>]

>> Date: Sun, 28 Sep 2003 18:23:40 -0400
>> From: Andrew Cagney <ac131313@redhat.com>
>> 
>> 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
> available?

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.

enjoy,
Andrew