breakpoint extension for remote protocol, take II

J.T. Conklin jtc@redback.com
Mon Jun 14 17:34:00 GMT 1999


>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan>    Bleh.  But that's what the 'q' escape is for.  IMO, all
Stan>    experimental protocol extensions should be using 'q';
Stan>    likewise, GDB should never use 'q' itself.
Stan>
Stan> You mean like with qOffsets, that's been standardly issued by
Stan> GDB for years? :-)
Stan>
Stan> Actually, I don't ever remember hearing that 'q' was supposed to
Stan> be experimental, and the existing docs don't seem to say so
Stan> either.

Although I've had that (mis-)interpretation for years, you are right.
There is nothing that indicates that that 'q' is intended to be used
for experimental commands.  

Stan> At this point we would have to pick a different char I
Stan> think, and be very disciplined about not allowing any usages of
Stan> it into the standard sources, so that it really can be for
Stan> experimentation.

Agreed.

I'll try to weasel out of this mistake by arguing that there *should*
be letter reserved for experimental, and other non-standard commands.
The remote protocol is used beyond the cannonical implementations of
remote.c and the sample stubs provided with GDB.  Since the protocol
is relatively simple, it's not surprising that it has been extended.
And without a well developed specification and/or an organization to
register protocol extensions, it's not surprising that there have been
or could be collisions in those extensions.

Stan> In general, we have a sizeable documentation gap with the remote
Stan> protocol; it's become so ubiquitous it ought to have its own
Stan> RFC... :-)

Agreed again.  Even if the remote protocol is replaced with something
better :-), the old protocol won't go away for a long while.

	--jtc

-- 
J.T. Conklin
RedBack Networks


More information about the Gdb mailing list