breakpoint extension for remote protocol, take II

Jim Blandy jimb@cygnus.com
Wed Jun 16 14:06:00 GMT 1999


> > Actually, I don't ever remember hearing that 'q' was supposed to be
> > experimental, and the existing docs don't seem to say so either.  At
> > this point we would have to pick a different char I think, and be very
> > disciplined about not allowing any usages of it into the standard
> > sources, so that it really can be for experimentation.
> 
> I'd like to seriously propose that:
> 
> 	[qQ][A-Z].*
> 
> be reserved for GDB's internal use while:
> 
> 	[qQ][a-z].*
> 
> be declared as available for custom jobs.  In addition, custom packets
> include a clearly reconisable identifier vis:
> 
> 	qcygnus.badhack


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?

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.

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

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.

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


More information about the Gdb mailing list