This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]