Re: [PROPOSAL] Checking for supported packets

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 31 Mar 2006 09:19:58 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Fri, Mar 31, 2006 at 05:09:27PM +0300, Eli Zaretskii wrote:
> > > This is the first result for searching for empty response; it's in the
> > > remote protocol Overview section.  Is that sufficient?  Everywhere else
> > > it's just described as "empty" or "empty reply".
> > 
> > Let's make a point of saying ``empty response'' everywhere, okay?
> 
> Should we settle on "reply" or "response"?  I've been using response,
> but most packet's have a section labelled "Reply:" with an entry for
> "empty", which suggests that it is also or instead called an empty reply.

I don't mind using ``empty reply'' as long as we do that consistently.

> Oops, did I write that?  It's supposed to be "supported packets, remote
> query".
> 
> > > +@cindex @samp{qPacketInfo} packet
> > > +Tell the remote target about features supported by @value{GDBN}, and
> > > +query it for features it supports.
> > 
> > I think we need here an index entry that mentions the word
> > ``features''.  Observe how extensively you use it here and afterwards,
> > it's certainly something readers will try to search for when they are
> > looking for this description.
> 
> How about "features of a remote target, query"?  Oh, blast, that's
> ambiguous with the other proposal I posted (for registers et cetera).
> Does features need to be at the start of the index entry?  If not, how
> about "protocol features, remote query"?

No, ``features'' does not need to be the first word, although if it
is, users will see that entry when they type "i features TAB" in Info,
so it is desirable if possible.  "protocol features, remote query" is
okay, although we could also have "features of remote protocol, query
for support" or even simply "features of remote protocol" (since the
other index entries don't use ``query'' at all).

> That is, all four failed queries are consolidated to a single
> what-do-you-support query.  Sending a couple of additional bytes in the
> qPacketInfo response is generally less costly than waiting for four
> round trips, and it will be even more beneficial when packets not
> mentioned in qPacketInfo are assumed to be unsupported; for instance,
> the qPart:features packet I recently proposed would not be tried if
> qPacketInfo failed or if qPacketInfo didn't mention it, only if there
> was a qPart:features+ response.

Thanks.  But in practice, qPacketInfo could result in an empty reply,
so for stubs that don't support qPacketInfo, this addition is a
burden.  Should we have a facility to tell GDB not to use qPacketInfo?

In any case, I think this explanation should be in the manual, because
it is not immediately obvious that several short packets take so much
less time than one longer packet.

As another aside, you wrote in your original message:

  "Remote stubs are taught to ignore unknown packets and generate the
  empty response we expect."

Is there anything else included in ``ignoring'' besides the empty
response?  I'm asking because, in everyday's speech, ``ignore'' means
``do nothing'', not ``send a packet''.