This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Remote watchpoint support for FRV
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: gdb-patches at sourceware dot org
- Date: Fri, 5 Oct 2007 15:47:53 +0200 (CEST)
- Subject: Remote watchpoint support for FRV
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