This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
- From: Paul Koning <pkoning at equallogic dot com>
- To: orjan dot friberg at axis dot com
- Cc: eliz at elta dot co dot il, gdb-patches at sources dot redhat dot com
- Date: Wed, 8 Oct 2003 12:02:03 -0400
- Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
- References: <ur81oqb1c.fsf@elta.co.il><3F8412C1.8090908@axis.com>
>>>>> "Orjan" == Orjan Friberg <orjan.friberg@axis.com> writes:
Orjan> Eli Zaretskii wrote:
>> Perhaps none of the targets that support hardware read and access
>> watchpoints define HAVE_NONSTEPPABLE_WATCHPOINT?
Orjan> Yes, that seems to be the case.
No; I found that the SB-1 (a MIPS) needs to have this defined.
>> Anyway, from your description, it is quite clear that if a target
>> defines HAVE_NONSTEPPABLE_WATCHPOINT, GDB must call
>> target_stopped_data_address before it disables the watchpoint and
>> steps over it, or else the target end should store the necessary
>> info somewhere and deliver it when target_stopped_data_address is
>> called.
Orjan> Right. I was thinking I could make watchpoints "steppable" by
Orjan> disabling them in the remote stub when a watchpoint hits, and
Orjan> then enabling them again when a continue is issued, but it
Orjan> feels like that might create more problems than it solves.
Orjan> (For example, watchpoints would never hit when
Orjan> single-stepping.)
I agree. I ended up defining HAVE_NONSTEPPABLE_WATCHPOINT, and I had
to make a patch to deal with the target_stopped_data_address issue you
mentioned.
(In case someone wonders: this was on a private variant of a 5.3
snapshot; I haven't had enough time to try to submit it as mainstream
patches, and parts of what I did appear to be controversial -- such as
fixes for the broken shared library handling in that version at least
with MIPS NetBSD.)
paul