Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Paul Koning <paul_koning@dell.com>
To: Doug Evans <dje@google.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	Joel Brobecker <brobecker@adacore.com>,
	Yao Qi <yao@codesourcery.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: duplicated code in gdb and gdbserver
Date: Wed, 12 Jan 2011 18:43:00 -0000	[thread overview]
Message-ID: <BFFC118A-0E53-400A-A65D-F3623ECE1FE9@dell.com> (raw)
In-Reply-To: <AANLkTi=wECTapSS83jqfR30CLB-XrxBQ365bQmBNVr1O@mail.gmail.com>


On Jan 12, 2011, at 12:54 PM, Doug Evans wrote:

> On Wed, Jan 12, 2011 at 9:33 AM, Doug Evans <dje@google.com> wrote:
>> I think the remote protocol itself is getting old.
>> In days of multiple threads, inferiors, and architectures, plus an
>> expanding feature set, ISTM IWBN to start over.
> 
> Blech, sorry for the follow-up.
> I should add that these days packet size is often far less of an issue
> than latency.

I strongly disagree with that claim.

While the remote protocol often runs across TCP connections on LANs, it also often runs over UART ports, at speeds of 9600 baud or so.  Packet size is absolutely a very serious issue here.

For example, I ended up optimizing a kernel gdb stub for MIPS to generate T messages (extended stop messages, with a few registers included) to avoid the expense of the large "g" packet.  For that matter, I've found it very much worth while to implement the run-length encoding option in the protocol.

Latency too matters, but this is one of those protocols where saving bytes is a major consideration.

	paul


  reply	other threads:[~2011-01-12 18:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-07 15:23 Yao Qi
2011-01-07 16:37 ` Doug Evans
2011-01-08  3:34   ` Yao Qi
2011-01-08  5:17     ` Joel Brobecker
2011-01-10 13:39   ` Frank Ch. Eigler
2011-01-10 14:09     ` Joel Brobecker
2011-01-10 15:10       ` Frank Ch. Eigler
2011-01-10 15:50       ` Paul Koning
2011-01-10 15:51     ` Doug Evans
2011-01-10 15:54       ` Frank Ch. Eigler
2011-01-10 16:35         ` Doug Evans
2011-01-10 19:02           ` Frank Ch. Eigler
2011-01-11 23:35             ` Joel Brobecker
2011-01-11 23:38           ` Joel Brobecker
2011-01-12  0:30             ` Frank Ch. Eigler
2011-01-12 17:54               ` Doug Evans
2011-01-12 18:06                 ` Doug Evans
2011-01-12 18:43                   ` Paul Koning [this message]
2011-01-12 19:04                     ` Doug Evans
2011-01-12 20:09                 ` Joel Brobecker
2011-01-12 20:48                 ` Frank Ch. Eigler
2011-01-14 17:04                   ` Doug Evans
2011-01-12 15:47           ` Tom Tromey
2011-01-07 17:17 ` Stan Shebs

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=BFFC118A-0E53-400A-A65D-F3623ECE1FE9@dell.com \
    --to=paul_koning@dell.com \
    --cc=brobecker@adacore.com \
    --cc=dje@google.com \
    --cc=fche@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.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