Re: Tracepoint support in Cygnus GDB ?

[Jim Blandy <jimb at redhat dot com>]

Andrew Cagney <ac131313@redhat.com> 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
  archived messages.

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

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

  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.