Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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.


  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