Re: breakpoint extension for remote protocol, take II

[Andrew Cagney <ac131313@cygnus.com>]

Jim Blandy wrote:

> Does reserving prefixes for internal/custom/official packets really
> help?  You never know what's going to become popular, and once
> something does, it's too late to change all the random ROMS out there
> to expect a different letter, just to indicate the packet's new
> legitimacy.  Those are the forces carrying the design now, right?

I think it would.  There are actually a number of problems and I guess
I'm only addressing one of them.

The specific case I was thinking of was where a user wanted to enable
the querying/setting of things their specific target.

Another way to go would be to allow the protocol to tunnel generic
target monitor commands across.  I've seen several requests for this.


> If we're going to establish a policy, it should be one that allows a
> smooth transition of packets' status from "experimental" to
> "standard".  By `smooth', I mean that the packet itself shouldn't have
> to change simply because we've acknowledged it as widely useful.
> 
> Here's another proposal, which does allow smooth transitions: make the
> GDB maintainer responsible for allocating unique prefixes to anyone
> who asks for one, like the IANA.  Put a comment in remote.c suggesting
> that people extending the protocol ask for a prefix.

Yes, control mechanisms probably shouldn't be using the query packet.

> When a packet becomes popular, the GDB maintainer documents it.  No
> code changes.

One problem we've got now (for breakpoints/baud) is that there are
boards in the field that know about a `B' packet and it isn't the one
proposed.  If we send that board the new B packet it will accept it as
an old B packet fool GDB into thinking that that it has a modern board
:-(

Hmm, perhaphs GDB's startup should be doing an initial query that
returns a string indicating everything the board suports.  Something
like:

	<- QProtocol
	<- !1B1b1...

where the returned string consists of:

	{ <PACKET><VERSION-NUMBER> }

(``!1'' could be interpreted as extended remote).

> Note that there's no point in having a designated experimentation
> prefix, since that has exactly the problem we're trying to avoid.
> 
> Maybe we can list existing allocated prefixes in remote.c too, so
> people can say, "Oh!  My company already has a prefix!"  If the list
> gets large, we can move it elsewhere.

Good point.

Things to do inclues deleting the protocol description from every
remote*.c and *stub.c file I find and moving a summary to gdb/doc/

> I don't think we'll need to worry about abuse.  We are talking about
> GDB's remote protocol here, not domain names.

Andrew