GDB-Protocol: Version/Protocol packet

[Andrew Cagney]

Stan Shebs wrote:
> 
>    Date: Thu, 17 Jun 1999 10:58:27 +1000
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    While the current non-response schema works well for the case of an
>    unsupported packet it isn't so good at identifying a target that has
>    support for non-aproved packets.
> 
> OK, I'll bite - why would anyone care?  It seems unlikely that I as
> embedded developer would have a stub hacked for "non-approved"
> packets, but not also a GDB that was hacked to use them...
> 
>    In addition it doesn't address the
>    looming problem of actually running out of packet prefixes.
> 
> Well, after 15 years we've used about half the alphabet, so in, uh,
> 2014 we would have to go to **gasp** a second character.  Seeing as
> how 'q' is already being used to pass commands with various long
> names, the pressure to use new letters is even less than it was.
> 
> The danger I see here is that you're trying to anticipate problems
> that haven't actually occurred, so it's too hard to know whether the
> solution will work for problems that actually do occur; but if you've
> specified and implemented already, then you're stuck with supporting
> it, *and* you still have to add new code that solves the actual
> problems.

Perhaphs.

Looking at the ``q'' packet though, remote.c has managed to accumulate
code that rules out:

	qL.*
	qP.*
	qC.* (because of how one stub is written)

And I think I even saw a ``K'' somewhere.  At least the person that
added the CRC: packet got it right :-)

To close this one, what I intend doing is:

	o	tighten up the spec's for ``q'' so we don't
		get more bad packets

	o	pull this proposal and do the breakpoint
		packet proposal with ``zZ'' (for want of
		a better letter).

Andrew