This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint support in Cygnus GDB ?
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
(Snide remarks aside) I would go through the archives and the target
code (FIXME comments in remote.c, for instance) the the basic theory of
the target stack has been posted and discussed many times. The key word
"sandwich" in gdb@ throws up one such post :-)
Just, please don't look to me for highly detailed and definitive
interface specifications. I see no value in providing developers with
such a level of formalization. Let the person writing the code figure
out an interface that just meets the immediate need; and recognize that
in 6 months new requirements will change the interface anyway. No need
for immediate perfection.
- 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,
The problem will always be there, and can't simply be attributed to
employee pressure. As a reasonable generalization, people have a
tendency to try to avoid the hard but necessary work of peer review,
incremental design, shortcut avoidance, finishing features, writing
testsuites, .... We're all responsible for ensuring these things do occure.