Re: RFA: Document conventions for terminating query/set packet names

[Jim Blandy <jimb@codesourcery.com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Wed, May 03, 2006 at 12:50:59PM -0700, Jim Blandy wrote:
>> 
>> 2006-05-03  Jim Blandy  <jimb@codesourcery.com>
>> 
>> 	* gdb.texinfo (General Query Packets): Document conventions for
>> 	terminating packet names, and their violations.
>
> Sorry, forgot to mention something when we talked about this earlier. 
> I'm generally in favor of the newly documented conventions, except for
> this:
>
>> + Since this packet's name (@code{qP}) is not separated from its first
>> + argument (@var{mode}) by any kind of punctuation, it is ambiguous with
>> + the @code{qPart} packet.  Stubs should recognize this packet by the
>> + twenty-four hex digits that follow.  New stubs should implement the
>> + @code{qThreadExtraInfo} packet instead.
>> + 
>
> Background for the list: we discovered by accident yesterday that
> RedBoot interprets any other query packet starting with qP as a
> malformed thread info request.  Not surprising, since the format of qP
> doesn't have any separators in it.  So what's a "malformed qP packet"
> versus "some other packet that happens to start with qP"?
>
> I think the best solution would be to document that new packets should
> not start with "qP" or "qL", and rename the relatively new qPart packet
> to something else, like qXfer.  I don't really care whether GDB
> continues to try the old qPart name; I think it may be recent enough
> that we can drop it, but maybe not.  I believe the only thing it's used
> for on HEAD is the ELF Auxv vector; I have other uses on various
> branches, but none of them have been merged yet.
>
> Interested in any comments...

The protocol as currently documented is ambiguous.  Whatever we do in
the long run, I think the manual ought to make some recommendation now
to guide new implementations.  The 'count the hex digits' is one
approach; another would be to deprecate qP altogether, in favor of
qThreadExtraInfo.  That's what GDB prefers at the moment; it's been
around since 2000.  qP dates to GDB's prehistory, but I'm pretty sure
it's from around 1998; I was at Cygnus when it was discussed.

I looked around a bit; neither gdbserver nor RDA nor the stub we've
been working with recently within CodeSourcery implement qP.  RedBoot
does.  We might break less by explicitly deprecating qP, since we
already have a preferred alternative.

Gratuitous chart:

                              qP     qPart    qThreadExtraInfo
gdbserver                            x
RDA                                           x
internal CodeSourcery stub                    x
RedBoot                       x