This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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