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've redirected to gdb, since this is a more general discussion.) jtc@redbacknetworks.com (J.T. Conklin) writes: > This, plus changes like adding thread stuff into the 'q' escape > instead of making threads `first class objects' in the protocol; > adding 'X' for binary memory write instead of a true binary packet > mode; etc. has me thinking that it's time to re-design the remote > protocol from the ground up. This idea has been kicking around for quite some time, and it has a number of appealing points. I think the main disadvantage is that people's problems with the existing protocol tend to be minor, compared to the difficulties attendant upon introducing a new "standard" protocol, so hasn't been a huge demand to start over. There is also a lot of room for extension within the existing framework, and we've been able to add a bunch of extensions without causing major disruptions out in the world (as far as I've heard anyway :-) ). That said, if some energetic hacker were to drop a new and improved debug protocol in my lap, I would be very happy to add it into GDB. Your specific suggestions are good advice to that hacker, I don't have anything to add to most of them. > * Supports ascii and binary modes (Perhaps ascii is no longer needed; > I don't think many people are computing checksums by hand. And if > transport layer provides 8 bit clean path...) After spending some time with ARM's ADP, which is a complicated binary protocol, my enthusiasm for ASCII is rekindled. Binary protocol is great when everything works right; when it doesn't, life gets very painful. That's why it made sense to me to just add a couple optional packets to improve performance when and where it matters. Even doing encoding is problematic. SDS protocol (target sds) uses an amusing 6-bit encoding for packets so that they're still ASCII, but the packets are complete illegible and you need good debugging prints on both sides to display the actual packet. > * Provide a stub library that contains the guts of the protocol > engine that's linked with CPU/target specific routines. We have a half > dozen stubs that are distributed with GDB, where not even the "common" > code is exactly the same. In usenet, there are periodic calls for > additional stubs (ppc, arm, etc.) that are not distributed with GDB. A > library might be able to address both of these problems. The situation right now is that there is some ferment in stub development at Cygnus. For instance, eCos has been developing its own stubs, which is not real great for synchronization. At this point though I don't know how much more I can say about what's going on, but I'll poke at folks to decide how much to publicize. As far as I can tell, there are no deep dark secrets involved. Stan