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] |
"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.