Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT

[Orjan Friberg <orjan.friberg@axis.com>]

Eli Zaretskii wrote:
> 
> 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.

Ah, good suggestion.  Excellent in fact - both rwatch and watch/rwatch 
on the same variable work fine now.  Thanks a lot!

I was a bit worried, this being a remote target, that I'd have to 
remember the rwatch -> awatch conversion made internally in the stub, 
and report it as an rwatch when stopping.  But the watch/rwatch/awatch 
information in the stop packet isn't passed on from remote.c - it's only 
used to parse out the remote watched data address.

> 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.

Agreed.  I am quite happy to live with your suggested solution, at least 
for now.  I certainly don't have the audacity to suggest such changes 
should be made to accomodate a target that isn't even submitted yet ;) .

-- 
Orjan Friberg
Axis Communications