This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Remote watchpoint support.
- To: Mark Salter <msalter at redhat dot com>
- Subject: Re: Remote watchpoint support.
- From: jtc at redback dot com (J.T. Conklin)
- Date: 30 Oct 2000 12:39:53 -0800
- Cc: gdb-patches at sources dot redhat dot com
- References: <200010301416.e9UEG6m18981@deneb.localdomain>
- Reply-To: jtc at redback dot com
>>>>> "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