This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint support in Cygnus GDB ?
Andrew Cagney <firstname.lastname@example.org> writes:
> > Right -- please contribute support for native tracepoints!
> The literal interpretation of this suggestion is to go away and not
> come back until you've come up with an unmergable jumbo patch.
Geez. It's not as if I said, "--- and please do it badly!!!"
Saravanan, I think there are two points germane to your original post:
- At the moment, I don't know of any company that is investing effort
in the tracepoint support. But GDB's feature set is not restricted
to those things that a small group of corporations decide they want
in closed meetings. Anyone with the skills and the patience to work
through the design with the rest of the group, and the time to code
it up, can get a feature in. So if native support for tracepoints
is of interest to you, and you think you've got the skills and the
time, I really encourage you to take it on yourself.
The first step would be to start a discussion on this list and build
a consensus on how to do it. Michael and I would be happy to see
the tracepoint stuff worked on, so we'd help out as best we could.
If you convinced him you were serious, Andrew would probably explain
some of the things he hinted at in his previous message enough that
someone who doesn't actually share his cerebellum could start
working on them. Maybe he already has, and could post pointers to
- In the past, companies in positions of power have chosen to
implement various features in GDB as quickly and cheaply as
possible, and put off dealing with the impact on simplicity and
maintainability until never. I would say the original C++ and
thread support would fall in this category, but supporting (at one
point) forty-some architectures without much attention paid to the
interface between per-architecture and generic code had its effects,
Andrew's spent years doing work on GDB's fundamentals to disentangle
the architecture description system and the frame system. I just
re-did one architecture's frame handling using his new interfaces,
and it took me a single day to finish. This used to take me a week,
and it'd still be wrong.
David Carlton essentially volunteered a year of his time to work
with Daniel Jacobowitz to straighten out the C++ support. I'm not a
C++ user myself, but I understand it's vastly better than it used to
In this context, you can see why one would want to place an emphasis
on cleaning up some of the supporting infrastructure to make way for
native tracepoints, and then doing it right, rather than just
pursuing the shortest path.