Re: Tracepoint support in Cygnus GDB ?

Andrew Cagney
2003-09-28T22:23:56Z

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