Re: Tracepoint support in Cygnus GDB ?

[Eli Zaretskii <eliz at elta dot co dot il>]

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

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

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.

> 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?

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

> Is the request to support debugging i386 binaries on x86-64 a bug, 
> infrastructure, or a user visible feature?

A minor feature, IMHO.

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

If it does nothing else than improve "break main; run", then it's not
a feature.

> Is the lack of lazy breakpoints a bug, infrastructure or new feature 

IMHO, it's an improvement in GDB efficiency, but functionally it's
not a new feature.

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

A bug or a minor feature.

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