This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

(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,
  too.

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.


enjoy,
Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]