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 -- Piet Delaney Phone: (408) 200-5256 Blue Lane Technologies Fax: (408) 200-5299 10450 Bubb Rd. Cupertino, Ca. 95014 Email: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
