This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


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

Re: breakpoint extension for remote protocol


"J.T. Conklin" <jtc@redbacknetworks.com> writes:

> I've been tasked to add support for hardware watch/breakpoints over
> the remote protocol.  

The remote stub I implemented for Ascend routers manages breakpoints,
and doing so cuts way down on communication overhead--I recommend it.
Keep in mind that doing so makes the stub stateful, so you must now
pay attention to detecting and discarding duplicates.  It's not
generally an issue for point-to-point connections over serial, but we
also use UDP as a transport, and across multiple hops it's possible
for gdb to timeout and retransmit a breakpoint set or clear command,
and if the retransmit came because of delayed rather than non
delivery, the stub will receive both.  When two breakpoint-set
commands arrive, was the second a duplicate, or did the user set two
BPs at the same address?  It makes most sense to maintain a reference
count for each address with a BP on the gdb host side's cache, and
maintain only a simple list of BP addresses in the stub's cache.  The
gdb host issues the remote BP clear command only when the gdb host's
reference count reaches 0, and issue the remote BP set command only on
the first BP set at an address.