data tracepoints

["taylor, david" <david dot taylor at emc dot com>]

For some applications and/or targets, "bad things" happen if the wrong
thread / process stops at a breakpoint waiting for the user to do something.

For such applications, tracepoints are extremely useful.

Sometimes instead of "when the program reaches this location I want to do ...",
you have the situation "when this variable is accessed / written, I want to do ...".

If the hardware supports it, you can use hardware watchpoints.  But, if the wrong
thread / process stops, things do south.

We have implemented what, for lack of a better name, I'll call data tracepoints.
>From GDB's perspective, they are a kludge.  GDB knows nothing about them.
The GUI asks GDB the size of the variable -- which becomes the default number
of bytes to trace.  Through casting and overloading of some fields (e.g., number
of bytes to trace ==> step count), they get defined and then downloaded to the
target.

One of the kludges is that the actions must be in the 'while-stepping' part of the
tracepoint, or tdump will not dump the data collected.  [Since the tracepoint location
is a data address, it does not match the pc at the time of the collection, so GDB thinks
that the current trace frame is in the 'while-stepping' part of a tracepoint...]

I'd like to make it no longer be a kludge.

The number and length of hardware watchpoints is extremely limited.  So, the
number of data tracepoints is also extremely limited.  But, they have proven very
useful.

Adding support immediately raises a number of questions.

For starters, what should they be called?

Should they be just tracepoints with GDB knowing that they are different since they are
in data space, not text space?  Or should there be a new command -- perhaps 'dtrace'?

Also, is overloading the QTDP packet okay?  Or should there be a new packet for
data tracepoints?

Opinions?

David