This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: breakpoint extension for remote protocol, take II
>> 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
Jim> Does reserving prefixes for internal/custom/official packets
Jim> really help? You never know what's going to become popular, and
Jim> once something does, it's too late to change all the random ROMS
Jim> out there to expect a different letter, just to indicate the
Jim> packet's new legitimacy. Those are the forces carrying the
Jim> design now, right?
When I suggested a 'escape' command prefix I had in mind two groups.
One who will work with the GDB/remote protocol mainatainers to come up
with a suitable/acceptable specification for their extensions; And the
other that just wants to do their own thing. The escape command is
for that second group. It guarantees that future GDB/remote protocol
versions won't interfere with their extensions, and a the same time
ensures that changes the GDB/remote protocol won't be sidelined by
some extension that no one bothered to tell the maintainers about.
Jim> If we're going to establish a policy, it should be one that
Jim> allows a smooth transition of packets' status from "experimental"
Jim> to "standard". By `smooth', I mean that the packet itself
Jim> shouldn't have to change simply because we've acknowledged it as
Jim> widely useful.
Given the model I outlined above, this would only occur if someone in
the second group had: 1) a change of heart/philosophy and wanted to
contribute what had been a proprietary command, and 2) that that
command was generally useful. Perhaps I'm being unreasonable, but I
don't feel I have any obligation to those users to integrate their
command into the protocol unchanged, especially if there is a more
general/elegant scheme to do the same thing. I believe that to do
otherwise rewards rogue behavior.
Jim> Here's another proposal, which does allow smooth transitions:
Jim> make the GDB maintainer responsible for allocating unique
Jim> prefixes to anyone who asks for one, like the IANA. Put a
Jim> comment in remote.c suggesting that people extending the protocol
Jim> ask for a prefix.
As I've been toying with specifying a replacement remote protocol, I
thought of the tags used by TIFF (Tagged Image File Format). At first
glance, a raster graphics format and a debug protocol seem completely
different. But taken more abstractly, they are trying to accomplish
much the same things. Both have a set of core commands/tags, some
optional commands/tags, and possibly some proprietary commands/tags.
And like GDB, a program that manipulates TIFF files is required to
make the best of what's there. If a tag is presen't it doesn't
understand, it's skipped.
There was a central repository that allocated tags, I believe four per
company. TIFF's tag namespace was a lot larger than the single alpha-
betic characters used by the remote protocol, but the need for a new
commands for the remote protocol should be a lot less. It is only the
recent future (ie last few years) that so many new commands have been
added.
--jtc
--
J.T. Conklin
RedBack Networks