This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PROPOSAL] Checking for supported packets - revised


Daniel Jacobowitz <drow@false.org> writes:
> I haven't followed up on the qPacketInfo proposal in a while, but I
> certainly hadn't forgotten about it either.  I have several
> improvements stacked up in a row, and this one ought to get done first.
>
> On Sat, Apr 01, 2006 at 01:21:59PM +0300, Eli Zaretskii wrote:
>> 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?
>
> Yes, probably; I've added one in my working copy.
>
>> 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.
>
> Thanks, this is a good idea.
>
>> 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''.
>
> Nope, just the bit about "empty responses" described in the overview
> section.
>
> I've also revised the proposal in a couple of other ways:
>
>   - Clarified documentation about the interaction with new packets.
>
>   - A new "maybe" response, as in "maybe I support that packet, ask
>     me when you need it".  This turns out to be quite useful if you
>     have a remote protocol library separated from your target
>     management library, which seems reasonably common.  For instance,
>     a breakpoint-related target might not be supported on some
>     particular target board lacking the necessary debug register.
>     But the stub's internal interface may not facilitate checking
>     for this.  Rather than forcing stubs to change, let's be flexible.
>
>   - Packet renamed from qPacketInfo to qSupported following the recent
>     discussion of qC/qL/qP prefixes.  This is where we actually
>     discovered the problem; CodeSourcery's latest GDB release sends
>     qPacketInfo to RedBoot, which responds with "huh?  that's not a
>     valid qP packet - E01".
>
> Here are the new commands currently in my patch, and the updated
> protocol documentation.  If no one has any additional comments about
> it, I'll submit the corresponding code soon.
>
> +@item set remote load-offsets
> +@kindex set remote load-offsets
> +@cindex load offsets of remote targets
> +This command enables or disables the use of the @samp{qOffsets}
> +request packet.  This packet is used to find a relocated downloaded
> +image.  @xref{General Query Packets, qOffsets}, for more details about
> +this packet.  The default depends on the remote stub's support of this
> +packet (@value{GDBN} queries the stub when this packet is first
> +required).
> +
> +@item show remote load-offsets
> +@kindex show remote load-offsets
> +Show the current setting of @samp{qOffsets} packet usage.
> +
> +@item set remote supported-packets
> +@kindex set remote supported-packets
> +@cindex query supported packets of remote targets
> +This command enables or disables the use of the @samp{qSupported}
> +request packet.  @xref{General Query Packets, qSupported}, for more
> +details about this packet.  The default is to use @samp{qSupported}.
> +
> +@item show remote supported-packets
> +@kindex show remote supported-packets
> +Show the current setting of @samp{qSupported} packet usage.
>
>
>
> +@item qSupported @r{[}:@var{feature} @r{[};@var{feature}@r{]}... @r{]}
> +@cindex supported packets, remote query
> +@cindex features of the remote protocol
> +@cindex @samp{qSupported} packet
> +Tell the remote target about features supported by @value{GDBN}, and
> +query it for features it supports.  This packet allows @value{GDBN}
> +and the remote target to take advantage of each others' features.
> +It also can eliminate excessive round trips when connecting to
> +a target; on high-latency links, a single @samp{qSupported} packet
> +is faster than a series of probe packets for unsupported packets.
> +
> +No values of @var{feature} are defined yet.  Targets should ignore any
> +unknown values for @var{feature}.  Any @value{GDBN} which sends a
> +@samp{qSupported} packet supports receiving packets of unlimited
> +length (earlier versions of @value{GDBN} may reject overly long
> +responses).  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.

I think it's a bit clearer to say "must not" instead of "may not"; the
latter hits my ears as "might not".

> +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 (see below
> +for a list of communication parameters).
> +@item @var{name}+
> +The remote protocol packet @var{name} is supported.
> +@item @var{name}-
> +The remote protocol packet @var{name} is not supported.
> +@item @var{name}?
> +The remote protocol packet @var{name} may be supported, and @value{GDBN}
> +should attempt to detect the packet when it is needed.  This is useful
> +when a stub's internal architecture does not allow the protocol layer
> +to know some information about the underlying target in advance.
> +@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.  @value{GDBN} will send packets up to this size for bulk
> +transfers, and will never send larger packets.  This is a limit on the
> +data characters in the packet, including the frame and checksum.
> +There is no trailing NUL byte in a remote protocol packet; if the stub
> +stores packets in a NUL-terminated format, it should allow an extra
> +byte in its buffer for the NUL.
> +@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

Doesn't that indicate that the target does not support software
breakpoints, as well?

> +made for @samp{qPart:@var{object}} packets; the name of the packet
> +includes the @var{object}, but not the @var{annex}.  Individual
> +@samp{qPart} objects 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{qSupported} query
> +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{qSupported} is supported and the new packet is reported in the
> +@samp{qSupported} response.  Any such packets will be listed here,
> +and their documentation will refer to @samp{qSupported}.
> +

It seems to me that GDB should assume that if a packet isn't
mentioned, it's not supported.  My thinking is:

- As GDB grows new packets over time, if GDB does not assume these new
  packets are unsupported if unmentioned, then we'll grow a new series
  of round trips with older stubs that do support the qSupported
  packet.  If we're going to go to all this trouble, let's get rid of
  these round trips once and for all.

- Under the rule I'm suggesting (call it "unmentioned means
  unimplemented"?), if a stub supports a new packet but doesn't
  mention it, GDB will never send it.  So stub implementors have an
  incentive and a reminder to keep their qSupported responses up to
  date.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]