Re: Remote watchpoint support.

[Fernando Nasser <fnasser at cygnus dot com>]

Michael Snyder wrote:
> 
> 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?

Yes, I am proposing a gdbarch entry + a target vector entry to deal with
the differences in how things are supported.  My goal was only to be able to
tell the user if we had resources for hardware watchpoints at the time he/she
requested instead of failing when the inferior is run or continued.  I need
it for the GUI.

It seems a little bit orthogonal to what Mark is requesting.




-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9