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] |
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