This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Take three: [PROPOSAL] Checking for supported packets
On Tue, May 23, 2006 at 02:31:55PM -0400, Daniel Jacobowitz wrote:
> Coming to a conclusion on which one of these options was "best" is not
> coming along well; Jim and I and some other coworkers talked about it
> for a long while yesterday, and ended up waffling. Mark suggested that
> I put together some hard numbers, so that we could see what we were
> really dealing with.
It's coming along much better now :-) I'd like to thank my coworkers,
particularly Jim, Sandra, and Paul, for their feedback. I am
completely happy with this version. It's changed a bit: it
addresses a much more restrictive problem, rather than automatically
applying to all packets. Also the documentation is much clearer.
This is a plaintext version of my current proposal; I'll post the
texinfo separately later - the nested tables make it very hard for
me to look over the text and get the structure. qXfer:features
is just an example; I wanted to fill in the table properly, but
I haven't fully proposed the qXfer:features packet yet. That
will be along shortly.
I'm planning to go ahead with this version, unless of course anyone has
concerns about it. It's going to require a bit of a revamp of my code,
though, so I won't be doing that until next week. As always, I am
entirely appreciative of feedback, even if you don't like my choices
:-) This version is, IMO, much superior to the first version I posted
a month ago (although it's taken far too long for comfort).
`qSupported [:GDBFEATURE [;GDBFEATURE]... ]'
Tell the remote stub about features supported by GDB, and query
the stub for features it supports. This packet allows GDB and the
remote stub to take advantage of each others' features.
`qSupported' also consolidates multiple feature probes at startup,
to improve GDB performance--a single larger packet performs better
than multiple smaller probe packets on high-latency links. Some
features may enable behavior which must not be on by default, e.g.
because it would confuse older clients or stubs. Other features
may describe packets which could be automatically probed for, but
are not. These features must be reported before GDB will use
them. This "default unsupported" behavior is not appropriate for
all packets, but it helps to keep the initial connection time
under control with new versions of GDB which support increasing
numbers of packets.
Reply:
`STUBFEATURE [;STUBFEATURE]...'
The stub supports or does not support each returned
STUBFEATURE, depending on the form of each STUBFEATURE (see
below for the possible forms).
`'
An empty reply indicates that `qSupported' is not recognized,
or that no features needed to be reported to GDB.
The allowed forms for each feature (either a GDBFEATURE in the
`qSupported' packet, or a STUBFEATURE in the response) are:
`NAME=VALUE'
The remote protocol feature NAME is supported, and associated
with the specified VALUE. The format of VALUE depends on the
feature, but it must not include a semicolon.
`NAME+'
The remote protocol feature NAME is supported, and does not
need an associated value.
`NAME-'
The remote protocol feature NAME is not supported.
`NAME?'
The remote protocol feature NAME may be supported, and GDB
should auto-detect support in some other way when it is
needed. This form will not be used for GDBFEATURE
notifications, but may be used for STUBFEATURE responses.
Whenever the stub receives a `qSupported' request, the supplied
set of GDB features should override any previous request. This
allows GDB to put the stub in a known state, even if the stub had
previously been communicating with a different version of GDB.
No values of GDBFEATURE (for the packet sent by GDB) are defined
yet. Stubs should ignore any unknown values for GDBFEATURE. Any
GDB which sends a `qSupported' packet supports receiving packets
of unlimited length (earlier versions of GDB may reject overly
long responses). Values for GDBFEATURE may be defined in the
future to let the stub take advantage of new features in GDB, e.g.
incompatible improvements in the remote protocol--support for
unlimited length responses would be a GDBFEATURE example, if it
were not implied by the `qSupported' query.
Similarly, GDB will silently ignore unrecognized stub feature
responses, as long as each response uses one of the standard forms.
Some features are flags. A stub which supports a flag feature
should respond with a `+' form response. Other features require
values, and the stub should respond with an `=' form response.
Each feature has a default value, which GDB will use if
`qSupported' is not available or if the feature is not mentioned
in the `qSupported' response. The default values are fixed; a
stub is free to omit any feature responses that match the defaults.
Not all features can be probed, but for those which can, the
probing mechanism is useful: in some cases, a stub's internal
architecture may not allow the protocol layer to know some
information about the underlying target in advance. This is
especially common in stubs which may be configured for multiple
targets.
These are the currently defined stub features and their properties:
Packet Name Value Default Probe Allowed
Required
`PacketSize' Yes `-' No
`qXfer:features' No `-' Yes
These are the currently defined stub features, in more detail:
`PacketSize=BYTES'
The remote stub can accept packets up to at least BYTES in
length. GDB 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. If this stub feature is not supported,
GDB guesses based on the size of the `g' packet response.
`qXfer:features'
The remote stub can respond to the the `qXfer:features' query
(*note `qXfer:features': qXfer features.).
--
Daniel Jacobowitz
CodeSourcery