Remote watchpoint support for FRV

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Hello,

the tm-frv.h header file overrides a number of watchpoint related
target macros, in particular:

#define STOPPED_BY_WATCHPOINT(W) \
   ((W).kind == TARGET_WAITKIND_STOPPED \
   && (W).value.sig == TARGET_SIGNAL_TRAP \
   && frv_have_stopped_data_address())

Note that FRV is a remote-only target, so this will affect and
modifiy the behaviour of the remote.c watchpoint handling.

Apparently the intent is to use the standard remote protocol
mechanisms to *set* watchpoints, but change the way to test
whether a watchpoint was hit.  Usually, remote.c would rely
on the remote stub to detect this condition and report it
via a "watch" stop reason in the stop reply packet.

However, due to the tm-frv.h override, for FRV targets GDB
will actually perform the check on the host side (by reading
control registers via the normal register access protocol).


To get rid of the TM header file, I can see two options:

- Simply remove support for this way of handling remote 
  watchpoints.  Existing FRV remote stubs will need to be
  changed to use the standard "watch" stop reason code.

- If we think we cannot break existing FRV stubs, I'd
  suggest to add new gdbarch callbacks that will be used
  by the remote target to allow architecture-specific
  overrides of the remote watchpoint mechanism, e.g.:
    
     gdbarch_remote_stopped_by_watchpoint
     gdbarch_remote_stopped_data_address
     gdbarch_remote_check_watch_resources


Any opinions on this?  The first option would obviously be
the easiest to implement in GDB, but I'm not sure what extent
FRV remote stubs are currently in use ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com