Hi piet, I found this reference to the GDB protocol specification
http://davis.lbl.gov/Manuals/GDB/gdb_31.html get_packet() is the receive protocol "deframing" function. It's job is to validate the received "packet" for conformance to the protocol packet format and to extract the payload eg. get the gdb command/response "message". The reason that the $ and # are unique within a packet is to allow get_packet() to explicitly detect the start of a new packet and to determine when to expect the checksum digits. These characters must not appear within the payload. Clearly the existing get_packet() fails to check at all times for the reception of a $. Therefore, the code can easily miss the start of a new packet, this means that the handling of the previous packet was aborted. I suspect the existing get_packet() function has been used for years so people may think it works OK and maybe reluctant to make changes. It is easy to demonstrate that the existing get_packet() fails to detect malformed packets. In particular the 2nd packet received after a bad packet is received is very likely to be lost. You will notice that the serial interface is polled and waiting for a packet will block the transmission of a packet from the target. In other words half-duplex operation is used. Also, transmission of a packet from the target blocks reception of a packet. Note that Liberte Software Ltd. have submitted this enhancement as we are committed to the GPL and we think it improves performance. We have created this enhancement for a client. It maybe interesting to create a test specification to demonstrate that the existing get_packet() does not correctly check the protocol "framing" under error conditions ? Fixing get_packet() should reduce the number of re-tries sent by gdb and the target should be more responsive in producing ACK (+) and NAK (-) indications. Thank you for your interest. Dean. On Tue, 2006-10-17 at 17:29 -0700, Piet Delaney wrote: > On Tue, 2006-10-17 at 18:53 +0100, Dean Jenkins wrote: > > Where is "the protocol specification"? > > Last I recall it was with the code doing kgdb_handle_exception(). > Didn't see anything in one are of gdb's remote.c explicitly > stating the protocol. > > I like your idea of making the serial interface more robust > but wonder if it's overkill. It's currently not very reliable. > I noticed that kgdb over Ethernet often breaks when I leave a > session running overnight. > > -piet > > > Hi Tom, > > > > Thank you for your time at looking at my proposed enhancement. > > > > I've attached a kgbd.c.udiff file containing the output of diff -u. > > > > Well, you are right about the protocol specification, unfortunately the > > existing get_packet() fails to implement the correct protocol error > > handling ! > > > > There are many scenarios where the existing get_packet() fails and will > > not produce a NAK or ACK at the correct time. This causes gdb to > > retransmit multiple times trying to get the get_packet() code to > > respond. This can be improved by using proper protocol decoding :) > > > > The protocol is designed to have unique $ and # markers. Therefore, $ > > always indicates the start of a new packet and should be trapped. The > > existing code can fail to spot a new packet if the previous packet was > > bad. eg. # character corrupt or missing. This causes the next "good" > > packet to be incorrectly decoded as the code is stuck in a loop waiting > > for a # of the previous packet. > > > > For me, state machines are ideal for decoding this layer 2 protocol and > > because it uses a single call to the read function. In other words the > > flow of the code is dependent on the "meaning" of the received data and > > the current state rather than a fixed sequential flow. > > > > In my opinion, the existing get_packet() only works when the comms are > > 100% good. In which case why bother with the checksum ? > > > > I have many years of experience of layer 2 protocols on embedded systems > > and I was horrified to see the existing get_packet() implementation and > > I therefore posted a better solution for you to consider. > > > > I understand that my enhancement is crucial to the performance of the > > protocol link and I welcome feedback. However, I think the existing > > get_packet() code is broken and needs fixing :) > > > > It is quite easy to see that existing get_packet() is broken, for > > example using minicom try to send the following "connect" sequence to > > kgdb > > > > $?#3$?#3f > > > > The last checksum digit of the first packet is missing but results in no > > ACK (+) being produced for the good packet $?#3f. Whereas my solution > > detects the $ of the second packet and aborts the decode of the first > > packet resulting in ACK being produced. This scenario could happen if > > the cable is disconnected whilst gdb is trying to connect and then > > sometime later ( could be 6 months later, there is no timeout ) the > > cable is reconnected. > > > > Thanks for your interest in my solution. > > > > Regards, > > Dean. > > > > > > On Tue, 2006-10-17 at 09:52 -0700, Tom Rini wrote: > > > On Tue, Oct 10, 2006 at 01:35:42PM +0100, Dean Jenkins wrote: > > > > > > > Hi, > > > > > > > > I am a newbie to this process so please tell me if I need to make > > > > changes to this message. > > > > > > > > I wish to submit an enhancement to replace the original get_packet() > > > > function in kgdb.c. Please give me some feedback. > > > > > > Can you please resend this as a Unified Diff (diff -u) ? Thanks! > > > > > > But generally, I'm not sure about this change. The protocol itself is > > > defined in a way that if we get a bad or garbage packet, we just NAK and > > > the other side (or us, if we see the NAK) resends. > > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job > > easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ Kgdb-bugreport mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
