[PROPOSAL] Checking for supported packets

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Mar 21, 2006 at 12:12:21AM -0500, Daniel Jacobowitz wrote:
> I intend to turn this particular example into a more thought-out
> proposal this week.  And if I'm really lucky, I'll have the
> target-defined features proposal ready this week also; but don't
> hold your breath, it might be next week.

That one escaped first, as it happens.  Here's the other.

Restating the problem:

Whenever we connect to a remote target, we set a number of packets
to auto-detect.  The first time they are needed, we send them, and
interpret an empty response as "unsupported".  Remote stubs are
taught to ignore unknown packets and generate the empty response we
expect.

The down side of this is performance.  Some of the probes are in
response to direct user commands, and those are only a small nuisance,
e.g. qGetTLSAddress will be generated in response to an attempt to
print a TLS variable.  But some commands generate more than one.
Particularly important is the initial connect (which probes for
qOffsets, various thread packets, and more to come in my future
proposals - which is why I'm tackling this first).  Also of interest
is the first continue or step, which probes for vCont and also an
assortment of breakpoint related packets (typically Z0 to set a
breakpoint, and if that fails X to do binary download, and only then
falling back to M).

Other problems I decided to fix at the same time:

We guess very conservatively at the maximum supported packet size
by the remote stub, in order to support simplistic stubs which don't
do decent bounds checking.  Many modern stubs support larger transfers,
and larger transfers are more efficient.  Over TCP this can make a huge
difference for "load".

We have no way to tell the stub about responses we can understand, but
earlier versions of GDB would have choked on.  For instance, I proposed
a month or two ago for qPart responses to use a trailing '=' as an
end-of-object marker, to save an extra packet round trip.  This could
generate an error if the client doesn't support it.  So when I
implement that, soon, I'll add a feature notification for it.

Here's the actual proposal, in texinfo.  I also have a tested
implementation of this, which I will not post right away; I'd
like feedback on the interface first, if anyone has comments.

(Is Texinfo or makeinfo's text output more useful for proposals?
I can do either.)

@@ -23241,6 +23255,59 @@ encoded 32 bit mode; @var{threadid} is a
 
 Reply: see @code{remote.c:remote_unpack_thread_info_response()}.
 
+@item qPacketInfo @r{[};@var{feature}@r{]}...
+@cindex support packets, remote query
+@cindex @samp{qPacketInfo} packet
+Tell the remote target about features supported by @value{GDBN}, and
+query it for features it supports.
+
+No values of @var{feature} are defined yet.  Targets should ignore any
+unknown values for @var{feature}.  Any @value{GDBN} which sends a
+@samp{qPacketInfo} packet supports receiving packets of unlimited
+length.  Values for @var{feature} may be defined in the future to let
+the stub take advantage of new features in @value{GDBN}, e.g.@:
+incompatible improvements in the remote protocol.
+
+The reply is one or more feature responses, or empty if this packet is
+not supported.  Multiple feature responses are separated by semicolons,
+and individual feature responses may not include semicolons.  @value{GDBN}
+will silently ignore unrecognized feature responses, as long as the
+unrecognized response has one of the standard forms.  The standard forms
+are:
+
+@table @samp
+@item @var{name}=@var{value}
+Set a remote communication parameter to the specified value.
+@item @var{name}+
+The remote protocol packet @var{name} is supported.
+@item @var{name}-
+The remote protocol packet @var{name} is not supported.
+@end table
+
+Currently only one communication parameter is supported:
+
+@table @samp
+@item PacketSize=@var{bytes}
+The remote target can accept packets up to at least @var{bytes} in
+length.
+@end table
+
+The name of a packet which can be marked as supported or unsupported
+is the text of the packet in this documentation, up to but not
+including the first punctuation character or variable.  For example, a
+target which supports hardware watchpoints but not hardware
+breakpoints might report @samp{Z0-;Z1-;Z2+;Z3+;Z4+}.  An exception is
+made for @samp{qPart:@var{object}} packets; the name of the packet
+includes the @var{object}, but not the @var{annex}.  Individual
+@samp{qPart} packet types must be reported separately.
+
+Currently, all remote packets which are not mentioned in the response
+will be probed individually, just as if the @samp{qPacketInfo} command
+was not supported.  In the future, some new packets may be added to
+the remote protocol which will be assumed to be unsupported unless
+@samp{qPacketInfo} is supported and the new packet is reported in the
+@samp{qPacketInfo} response.
+
 @item qPart:@var{object}:read:@var{annex}:@var{offset},@var{length}
 @cindex read special object, remote request
 @cindex @samp{qPart} packet


-- 
Daniel Jacobowitz
CodeSourcery