This is the mail archive of the 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]

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.

          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:

          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.

          The remote protocol feature NAME is supported, and does not
          need an associated value.

          The remote protocol feature NAME is not supported.

          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

     These are the currently defined stub features and their properties:

     Packet Name       Value         Default       Probe Allowed
     `PacketSize'      Yes           `-'           No
     `qXfer:features'  No            `-'           Yes

     These are the currently defined stub features, in more detail:

          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.

          The remote stub can respond to the the `qXfer:features' query
          (*note `qXfer:features': qXfer features.).

Daniel Jacobowitz

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