This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]