breakpoint extension for remote protocol, take II

Jim Blandy jimb@cygnus.com
Thu Jun 17 13:38:00 GMT 1999


> 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.

Right.  Like writing a free debugger.  "Rogue" seems hard to
distinguish from "independent-minded."

I don't think we accomplish anything by making it hard for
independently developed extensions to become official.

Allocating prefixes to developers on request accomplishes your goal
above --- avoiding interference between the GDB maintainers and
independent projects --- and also makes it easy (a no-op, as far as
the code is concerned) for rogue developers to return to the fold.

And finally, it doesn't seem like much more work.  Maybe others
disagree.


More information about the Gdb mailing list