RE: (hardware) watchpoints and actions

[<duane at duaneellis dot com>]

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

david> Further, GDB must remain connected to the target.

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

Two problems you need to address:

a) Most "gdb-server" type things are rather "dumb" they do not know what
symbols are.
    GDB's protocol speaks "address" as an integer like value, not
symbolic.
    GDB's protocol has no idea what base+offset might be.
    GDB's protocol has no concept of "stack" or "register" based
variables.
    The STUB or GDB-SERVER has no access to the dwarf (or whatever)
debug information

Example: A linked list, you want to trace some data element, i.e.: 
trace( listPtr->Data )

At the breakpoint:

The variable: "listPtr" might be on the stack or a register
The Element "DATA" is at some base + offset

Thus you can only trace global variables
Secondary problem:  Has the compiler optimization updated the global? Or
is it still in the register?

How do you plan to solve this? I am also ignoring ENDIAN issues here.

b) Something in the target must 'interpret' the series of commands to
execute when the watch point hits.

Your options are: Install a small script interpreter into he
gdb-stub/gdb-server 
This might work for a GDB-SERVER on linux... you have a rich
environment.
Again - same problems as  above (access to debug information)
It does not work well for JTAG type GDB-Servers.

The other option something like GDB-STUBS (rom-monitor based) solution,
when the breakpoint/watchpoint exception occurs
For example - you could do sometime of JIT compilation, and download
code to the target that executes when the exception occurs.

A simple example might be you insert a "JSR my_bp_handler" at the
breakpoint location. 
That JSR/CALL does something special.

Questions (only a few)
  Where do you locate the code it jumps to?
  Can you modify the code? (is it in FLASH memory, or ReadOnly memory?)
  Can you modify the memory region attributes (i.e.: MMU bits) that
allow execution in that area?

------

Don't get me wrong, I am very aware of the problem you want to solve,
and the challenges
A good example might be a PID loop motor control, 100 times a second the
CPU calculates 
new motor control variables and must re-write hardware registers
otherwise the motor suddenly stops.

Other examples might be a network protocol with data flowing... you have
overrun and lost packets if you do not respond in time

What actually works better is a hardware based trace scheme, and that is
*VERY* chip/silicon/vendor specific.  One example is the ARM STM (system
trace macrocell)

But the code that supports this type of stuff often works better if it
is compiled into the actual application, which to some degree violates
the "do not ship debug code in production code" rule.

-Duane.