Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
Orjan Friberg
orjan.friberg@axis.com
Mon Apr 19 14:59:00 GMT 2004
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
More information about the Gdb-patches
mailing list