Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: gdb@cygnus.com
Subject: Re: remote protocol checksum and binary download
Date: Mon, 12 Apr 1999 19:27:00 -0000	[thread overview]
Message-ID: <199904130227.TAA17991@andros.cygnus.com> (raw)
In-Reply-To: <5m7lrhl3rw.fsf@jtc.redbacknetworks.com>

   From: jtc@redback.com (J.T. Conklin)
   Date: 12 Apr 1999 18:15:15 -0700

   First of all, while investigating this issue I decided to upgrade from
   4.17.86 to 4.17.87 --- it appears that gdb-4.17.87.tar.gz is truncated.

Several other people got it to work, so maybe something ate your
download?  Anyway, jimb neglected to tell anyone here, but in fact the
4.18 release is out - and somebody has already found and reported a
bad bug, in x86 Solaris.

   With the advent of the binary memory write command, checksums may be
   eight bit values.  However, both the sample stubs and the gdbserver
   program strip the high bit of all characters as they are received.
   This can cause the in-packet and computed checksums to disagree.  

Yes, the binary download option has been no end of trouble - it's a
good reminder of why we do a 7-bit protocol in the first place!  You've
identified some real problems, and I expect that Andrew C. and others
will mobilize to bash on them.

   I should have cought this before 4.18, but I got a bit caught up at
   work.  However, it's pretty much a show-stopper for using the remote
   protocol on the x86, due to the 0xcc breakpoint insn pretty much
   ensuring checksum mismatches..

   Perhaps the remotebinarydownload variable should default to 0.

Given that we'll probably have to do a point release to fix the x86
Solaris failure, this might be a good idea too for that release.  (For
some reason I thought it was already defaulting to 0, but the sources
say no.)

   I can't imagine anyone
   actually downloading code using the remote protocol --- net booting,
   ROM emulators, etc. are significantly less expensive than an
   engineer's time.

I think that's true for "serious" development - but for things like
eval boards (Hitachi's for example), remote protocol is all you can
afford.  Since that's also a first impression for using GDB, it's a
good idea to try to make it faster.  Still, it's more important that
it work correctly...

							Stan


  reply	other threads:[~1999-04-12 19:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-12 18:15 J.T. Conklin
1999-04-12 19:27 ` Stan Shebs [this message]
     [not found] ` <199904130227.TAA17991.cygnus.gdb@andros.cygnus.com>
1999-04-13 21:02   ` 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=199904130227.TAA17991@andros.cygnus.com \
    --to=shebs@cygnus.com \
    --cc=gdb@cygnus.com \
    --cc=jtc@redback.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