How about if such targets would set a read/write (i.e. access)
watchpoint, and then use the same logic as i386: if the value didn't
change, don't announce the rwatch hit? In effect, you would be
emulating i386 behavior.
That's a band-aid, I know. But to get rid of this mess altogether,
the GDB's watchpoint processing will need to be thoroughly revamped.
In particular, instead of walking all the watchpoints armed only with
the address that caused the inferior to stop, we would need to have
the target to tell us exactly what watchpoint triggered, and why.
That would mean pushing most of the related logic in
bpstat_stop_status into the target/architecture vectors, leaving the
GDB's application level with only the higher-level API that
communicates with the lower-level layers via watchpoint handles of
some kind.