Re: Remote watchpoint support.

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Mark" == Mark Salter <msalter@redhat.com> writes:
Mark> I'm adding hw break/watchpoint support to a remote target. I'm using
Mark> the Z-packet support that is in remote.c to install/remove the
Mark> watchpoints and breakpoints. When a watchpoint is triggered by a
Mark> read access, GDB needs a way to tell if the target stopped because 
Mark> of the watchpoint. This is done through a target specific function:
Mark>
Mark>   CORE_ADDR target_stopped_data_address(void)
Makr>
Mark> which returns the address of the data access which triggered the
Mark> watchpoint. If the target did not stop because of a watchpoint,
Mark> target_stopped_data_address should return zero. Past implementations
Mark> of watchpoints for remote targets have relied on special registers
Mark> returned in the 'g' packet to determine the data address.
Mark>
Mark> Rather than having gdb deal with the debug support registers directly,
Mark> I would like to add a remote protocol packet that can be used to
Mark> query the target for this address.

I was unware of this macro, yet we've been using hardware watchpoints
on a i386 target using the remote protocol for about a year.  Now that
I've examined the code in breakpoint.c which invokes it, I must assume
that no one has tried to use read or access watchpoints.

I'm not sure I like the protocol change though.  

One thing I dislike about it is that the debug agent never explicitly
tells GDB that a watchpoint has been hit, but rather it is implicitly
coded in the return value of the query.  

The second is the return value of 0 if the target stopped for another
reason.  I (now) know that this is the current behavior of the target_
stopped_data_address() macro, but it use the one address that I think
might be very important to watch on targets where the zero page isn't
unmapped (in which case a reference would cause a exception/trap).
While it might not be possible to fix in GDB's internals for some
time, preserving it in the remote protocol for all time seems like a 
mistake.

I think the way I'd go about this would be to add additional return
codes.  In earlier messages, I have mentioned it would be desirable
for GDB to represent breakpoints and single steps distinctly from
exceptions (e.g., adding a TARGET_WAITKIND_BREAKPOINT and TARGET_
WAITKIND_STEP).  I don't know when (or if) we'll ever get around to
that, but now that I think about it there is no reason why external
protocols could not do so 'ahead' of GDB itself.  For the time being,
gdb would have to re-multiplex them into an SIGTRAP exception, but it
could also extract additional information (such as a watchpoint data
address) at the same time.

Thoughts?

        --jtc

-- 
J.T. Conklin
RedBack Networks