From: Greg McGary <gkm@eng.ascend.com>
To: "J.T. Conklin" <jtc@redbacknetworks.com>
Cc: gdb@cygnus.com
Subject: Re: breakpoint extension for remote protocol
Date: Wed, 23 Dec 1998 13:07:00 -0000 [thread overview]
Message-ID: <msww3i602l.fsf@tucson-net-82.eng.ascend.com> (raw)
In-Reply-To: <199812041858.KAA25185@jtc.redbacknetworks.com>
"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.
next prev parent reply other threads:[~1998-12-23 13:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-12-04 10:59 J.T. Conklin
1998-12-23 13:07 ` Greg McGary [this message]
[not found] <199812041858.KAA25185.cygnus.gdb@jtc.redbacknetworks.com>
1998-12-10 19:27 ` Andrew Cagney
1998-12-10 21:46 ` Stu Grossman
1998-12-11 11:59 ` J.T. Conklin
1998-12-11 14:30 ` J.T. Conklin
1998-12-11 11:24 ` J.T. Conklin
[not found] ` <13936.45476.191551.329690.cygnus.gdb@babylon-5.cygnus.com>
1999-04-01 0:00 ` Andrew Cagney
1999-04-01 0:00 ` J.T. Conklin
1999-04-01 0:00 ` Stan Shebs
1999-04-01 0:00 ` Jim Blandy
1999-04-01 0:00 ` Stan Shebs
1999-04-01 0:00 ` J.T. Conklin
[not found] <199901050119.RAA19672.cygnus.gdb@jtc.redbacknetworks.com>
1999-04-01 0:00 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=msww3i602l.fsf@tucson-net-82.eng.ascend.com \
--to=gkm@eng.ascend.com \
--cc=gdb@cygnus.com \
--cc=jtc@redbacknetworks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox