Re: Patch to add breakpoint extension to remote protocol

[Stan Shebs <shebs@cygnus.com>]

(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