Re: (hardware) watchpoints and actions

[Yao Qi <qiyaoltc@gmail.com>]

"taylor, david" <david.taylor@emc.com> writes:

> For instructions, GDB has breakpoints and tracepoints.  For data, GDB has
> watchpoints.  It would be nice if there was a data equivalent of tracepoints.
> There is processor support for a limited number of small locations to
> be watched.
> The goal is to run at full speed until a watched location is accessed in some
> prescribed manner.  At that time, like a tracepoint, execute some actions to
> collect information and then continue at full speed.

This is a useful feature IMO.  However, do we deal with the local
variable?  Like watchpoint, GDB should stop watching the address when
the program goes out of the scope of the local variable.

If GDB can only trace global variable, that is acceptable to me.

>
> I'd like for it to be a part of GDB and also to avoid the kludges.
>
> Two questions immediately come to mind:
>
> . what should the GDB user interface be?

In CLI, we've already had "trace", "ftrace" and "strace", so the command
can be "dtrace" (or "mtrace" if "dtrace" is misleading).  In MI,
-break-insert is to create breakpoint/tracepoint, probably we can add
"-m" option for creating "data tracepoint".

Beside tracepoint creation, we should think about finding traceframes
via command 'tfind'.  Nowadays, we have 'tfind pc', 'tfind outside' and
'tfind range'.  How do these commands handle trace frames collected by
"data tracepoint"? or what do 'tfind outside' and 'tfind range' mean
regarding "data tracepoint"?  We need to update the semantics "QTFrame"
packet accordingly.

>
> . what should the remote protocol messages be?
>

We can reuse and extend QTDP to download "data tracepoint".

> Opinions?  Thoughts?

-- 
Yao (齐尧)