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] |
I don't know whether this will be of any use to you or not. But it seems like a logical place to begin. ------- Start of forwarded message ------- Resent-From: GNU Mailing List Maintenance <gnu@prep.ai.mit.edu> Date: Wed, 26 Nov 1997 23:59:46 -0800 From: Pascal Martin <pmartin@earthlink.net> To: gnu@prep.ai.mit.edu Subject: over-the-ethernet debug stub Resent-To: gvc@prep.ai.mit.edu Hello. I have seen on your WEB pages a request for help for this project. Although I would have enjoyed volunteering, I currently have no time available. I do, however, have some experience on that subject, having designed and implemented a very similar debugger stub in a previous job. Here are some comments about your description of the project. It appears to me that such an Ethernet support would be an invaluable addition to the embedded environment support in GNU, so the stub should be designed for reuse ouside the HURD itself. - - protocols to be used. My experience is that it is always a bad idea to not use the Internet protocol suite, because most systems protect the low level Ethernet socket for obvious security reasons. Also, using the Internet suite is much more portable (including Windows 95/NT). I had developped a small UDP/IP suite which, compiled, took about 7 Kbytes of 68k code, despite the fact it was Ada sources. This implementation included ARP/RARP and ICMP/ECHO support, plus an auto-configuring routing table: * ARP/RARP is obviously a must-have and more recent alternatives are quite memory-hungry. * Having ping to work has been proven very useful. * The routing support made me able to debug a target in France from my workstation in San Diego (how fun !). In other words, UDP/IP is perfectly suitable for this project. Of course, UDP/IP packets may be lost, so each command must have a sequence number, the workstation must retry commands when it receives no answer (timeout), and give up after n retry (except may be after a "go" command, because you never know how long it will take..). The target side must reply to all commands, but must execute a command only once and be able to repeat its last reply. This involves at most a mere 1.5Kbytes of data (one Ethernet packet). A variant of the existing gdb remote debugging protocol is probably usable: just add a header to contains the sequence number. In any case, avoid double acknowledgment as I have seen in some product: the UDP packet was acknowledged, then the answer packet was sent (and acknowledged..). This was an artifact of reusing a protocol designed for RS232 lines, and this was really inefficient, and even less reliable. - - Ethernet sharing. What have been a major problem is to share the Ethernet access between the debugger and the applications. An acceptable solution was to let the debugger peek at each network packet received, so it can intercept debugger's commands when the application is running (so the debugger can do dumps or stop the application). - - auto-configured routing support. A target is always a server that answers to a debugger requests. That means a target always receives a packet from the workstation before it sends one of its own. Because of that it knows the _Ethernet_ address of the source. There are two cases: - the workstation is local. The Ethernet address is the address of the workstation. There is no need to issue an ARP request: we can fill the ARP table right now. - the workstation is on a remote network. The Ethernet address is then always the address of a router. Because Internet routes are almost always bi-directional, sending the answer packet to that router will initiate a successful routing trip to the workstation. It is then safe to associate the workstation's IP address with the _router_ Ethernet address. Conclusion: any valid debugger UDP/IP packet received can be used to blindly initialize an ARP cache entry. This is totally automatic, there is absolutely no configuration required, and there is not even really any routing code involved. .. and I never took any patent on this one, so I guess you can use it without any fear of being sued. I hope this may help some day.. Regards, Pascal MARTIN. ------- End of forwarded message ------- -- A wall of infinite dimension stands before the course of human evolution. It is the finitude of the earth and its resources. Steve Morningthunder Instituto de Física, Universidad Nacional Autónoma de México mthunder@gnu.org mthunder@jreyes.ifisicacu.unam.mx