RE: (hardware) watchpoints and actions

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

    From: duane@duaneellis.com [mailto:duane@duaneellis.com] 
    Sent: Wednesday, November 11, 2015 5:02 PM
    To: taylor, david; gdb@sourceware.org
    Subject: RE: (hardware) watchpoints and actions

    >> 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 sounds like a macro to execute on a (data|code) breakpoint.

        https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html

    Doesn't this already exist? If not, what part of this existing feature needs to be fixed?

    Or are you saying that the watchpoints do not support macros like as described above?

    If so, it seems the UI solution if needed would be the same as the existing breakpoint-commands.

    -Duane.

The beauty of tracepoints, and part of their reason for existing, is to have low
impact on the system being debugged.

Consider a remote target that you are communicating with via the remote protocol.
If the target's GDB stub does not support breakpoint commands or you wish to run
a command that is not convertible to a string of agent expression opcodes, then to
run the command there is a lot of back and forth between GDB and the target.

Further, GDB must remain connected to the target.

By contrast, when a tracepoint is hit, there is NO back and forth with GDB.
GDB might not even be connected to the target.  The target executes a series of
commands that were expressed as strings of agent expression opcodes and arguments.
A command might be to collect registers, or collect a particular variable or collect
some stack.  After the commands execute the program continues -- there is no
explicit 'continue' command.

The information collected from a particular hit of a tracepoint is called a trace frame.
Collectively, the trace frames are stored in a trace frame buffer.

Later GDB can reconnect to the target and examine the collected trace frames.

The idea is to support this for data, not just instructions.

Now, data is harder than instructions.  With instructions, you insert a breakpoint
Instruction, and when it is hit, you collect the information and then either do a
displaced step or replace the breakpoint with the instruction, single step, and put
the breakpoint back.  

With data, to do it at reasonable speed you need hardware support.  And our
hardware supports a small number of 'watched' locations.

If you try to trace a data location, GDB will report an error.  So, currently, our GUI
will take the expression given by the user, determine (by asking GDB) whether
the address is a data or instruction address.  If it is instruction, it acts as it has
for some time.  If it is data, it tells GDB to trace *address (which works).   If the user
did not specify a size to watch, then it uses GDB to get the size of the data item
(think: sizeof); if GDB doesn't know the size, it uses a default value for the size.
It currently uses the tracepoint step count [read: kludge] to pass the size to the
GDB stub.

The stub knows the memory layout, so it can easily determine whether the address
Is text or data and interpret the rest of the QTDV packet accordingly.

The above is somewhat tolerable when using the GUI.  But, I'd like to do it without
kludges.  I'd like data tracepoints to be first class citizens, not kludges.  Some people
[read: me, but there are others, too] like to use either the bare GDB or to use GDB
from within Emacs.  [I don't need no stinking GUI for GDB, I have Emacs.]

My preference would be for a new command -- dtrace, maybe?, for data tracepoints.
I'm less clear on what the interface should be for specifying the size.    I think passcount
makes sense; stepcount is, to me, less clear.  For the stub, something like
DataTracepoints[+-] as a qSupported response to determine whether the stub
supports data tracepoints, and I am ambivalent on whether there should be a new
remote protocol message or continue to use QTDV.

Hopefully that clarifies a few things.