Re: [PROPOSAL] Checking for supported packets

[Daniel Jacobowitz <drow at false dot 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 have one other comment to the text you posted:
> 
> > +@item qPacketInfo @r{[};@var{feature}@r{]}...
> > +@cindex support packets, remote query

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"?

> Btw, I'm not sure I understand how your suggestion fixes the
> performance issue, can you explain?

Here's the example from my original message:
  http://sourceware.org/ml/gdb/2006-03/msg00059.html

This is the sequence of packets on a first connect:

ending packet: $Hc-1#09...Ack
Packet received:
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: S00
Sending packet: $Hg0#df...Ack
Packet received:
Sending packet: $pf#d6...Ack
Packet received: 00000000
Packet p (fetch-register) is supported
Sending packet: $m0,4#fd...Ack
Packet received: 1000ffe7

If the remote target doesn't support p, we fall back to g, of course -
and that's yet another round trip.  It could be this instead:

-> qPacketInfo
<- Hc-,qC-,qOffsets-,Hg-
-> ?
<- S00
-> pf
<- 00000000

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.

-- 
Daniel Jacobowitz
CodeSourcery