remote protocol checksum and binary download

remote protocol checksum and binary download

[J.T. Conklin]

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.
Now to the meat of the issue.

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.  

GDB will retry the putpkt(), but since the problem is a fundamental
difference in the checksum definition, each retry will result in a
NAK.  This wouldn't be (as much of) a problem if GDB was able to
detect that the command was failing, but Like much of the rest of the
remote protocol implementation, remote_write_bytes() contains code of
the form:

	putpkt (buf);
	getpkt (buf, 0);

(ie, the return value of putpkt() is not checked).  Since the command
was never received by the stub, the getpkt() will time out.  

Unfortunately, remote_write_bytes() does not disable the use of the
'X' command because buf[] will contain the string 'timeout' instead
of '\0'.

This problem raises a handful of issues, so I don't really know where
to begin.

	* If the checksum only uses the least significant 7 bits, it
	  may cause undetected problems if the connection is not 8 bit
	  clean.  While an 8 bit checksum may cause problems in stubs
	  that are currently burned in firmware.

	* The return value of putpkt() should be examined.  If a
	  command was not received, there's no point waiting for a
	  response.

	* Perhaps there should be a real return value for getpkt() to
	  indicate errors, instead of overloading the return buffer.
	  In any case, something useful should be done on getpkt()
	  timeouts.

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.  I
suspect that of the four bulk transfers (memory read, memory write,
register read, and register write), memory write is the least used.
Register reads and writes are done all the time as you step through
code; memory reads happen when you traverse data structures; but
memory writes rarely happen in practice.  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.

	--jtc

-- 
J.T. Conklin
RedBack Networks

Re: remote protocol checksum and binary download

[Stan Shebs]

   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

Re: remote protocol checksum and binary download

[Andrew Cagney]

Stan Shebs wrote:
> 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.

The very strong rumor I've been given is that Keith Seitz fixed the
problem before 4.18 went out the door.  See:

1999-03-26  Jim Blandy  <jimb@zwingli.cygnus.com>

        Merged change from Keith Seitz:
        
        1999-03-16  Keith Seitz  <keiths@cygnus.com>

        * remote.c (reomte_binary_checked): New file global.
        (check_binary_download): New function to check if
        stub supports binary downloading that works with
        stubs that are not eight bit clean.
        (remote_write_bytes): Check for binary download capability
        and use it if available.
        Remove references to global remote_binary_length. What a hack.
        (putpkt_binary): New function.
        (putpkt): Call putpkt_binary.
        Use xor to escape trouble characters.

Andrew