Re: Remote watchpoint support.

[Michael Snyder <msnyder at redhat dot com>]

Mark Salter wrote:
> 
> >>>>> Michael Snyder writes:
> 
> > Mark Salter wrote:
> >>
> >> I'm adding hw break/watchpoint support to a remote target. I'm using
> >> the Z-packet support that is in remote.c to install/remove the
> >> watchpoints and breakpoints. When a watchpoint is triggered by a
> >> read access, GDB needs a way to tell if the target stopped because
> >> of the watchpoint. This is done through a target specific function:
> >>
> >> CORE_ADDR target_stopped_data_address(void)
> >>
> >> which returns the address of the data access which triggered the
> >> watchpoint. If the target did not stop because of a watchpoint,
> >> target_stopped_data_address should return zero. Past implementations
> >> of watchpoints for remote targets have relied on special registers
> >> returned in the 'g' packet to determine the data address.
> >>
> >> Rather than having gdb deal with the debug support registers directly,
> >> I would like to add a remote protocol packet that can be used to
> >> query the target for this address.
> >>
> >> Comments?
> >>
> >> --Mark
> 
> > That really sounds like more of a gdb thing.  xxx-tdep.c should have
> > the knowledge about the registers, though, not remote.c.
> 
> I'm trying to be consistent. Gdb already supports installing and deleting
> hw breakpoints and watchpoints via the Z packet in remote.c. Because the
> watchpoint support also needs to get the data address, it seemed right
> to do that through a packet in remote.c also.
> 
> I'm OK with putting the work of watchpoint support on the gdb side, its less
> work for me on the target side. But if we're going to add knowledge of debug
> support registers into gdb, then we might as well do the installing and
> removing of watchpoints via that mechanism instead of messing with a Z packet.

Oh.  Yes, I see what you mean.  Just ignore me.
J.T. should comment on this.  And maybe Fernando --
weren't you involved with the "z" packet, Fernando?