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]

Re: Remote watchpoint support.


"J.T. Conklin" wrote:
> 
> >>>>> "Michael" == Michael Snyder <msnyder@redhat.com> 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:
> 
> Michael> That really sounds like more of a gdb thing.  xxx-tdep.c
> Michael> should have the knowledge about the registers, though, not
> Michael> remote.c.
> 
> Well, that's one thing that Mark's change has going for it.  Like the
> "Z" packet, the proposed "qWaddr" packet knows nothing about how the
> target implements hardware break/watchpoints.  Those details are left
> up to the debug agent.  While it's probably processor debug registers,
> it could be an external device that speaks the remote debug protocol
> and talks to the target over BDM or some other on-chip-debugging tech-
> nology.

Yes.

There are two largely independant cases:

	o	gdb talking to a fully
		functioned target.

		Here the target is responsible for
		controling things like break/watch
		points and consequently is also
		responsible for returning indications
		that a break/watchpoint was reached.

		A remote target that supports Z packets
		is an example of this.  (only as
		Mark has pointed out, it has limited
		functionality)


	o	gdb talking to a minimal
		raw target.

		Here gdb implements the break/watch
		point functionality by directly
		accesing things like registers.

		x86 watchpoint registers is (?) an
		example of this one.

Before anyone tries to argue that one or the other is better, I think
they both are.  They solve different problems :-).  Now if only the
target vector was sufficiently clean to allow these to be stacked ....
:-)

	Andrew

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