Re: Tracepoint support in Cygnus GDB ?

[Andrew Cagney <ac131313@redhat.com>]

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