Re: [PROPOSAL] Checking for supported packets - revised

[Daniel Jacobowitz <drow at false dot org>]

On Wed, May 10, 2006 at 03:15:17PM -0700, Jim Blandy wrote:
> > +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".

Fixed.

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

Fixed, thanks.

> > +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.

I do not think that it is feasible to require an existing stub, when
adding qSupported support, to list the exact set of packets it
supports currently.  Also, it will make the reply much bigger, for
packets which might not be used in this session.  Do you think
it's worth it?  I could be persuaded, but I'm currently leaning
against; I'll explain my reasoning.

As a basis for comparison, gdbserver currently supports six packets
with long names, and roughly 28 packets with short names.  The reply
would be about two hundred bytes - not huge, but a bit unwieldy to
maintain.

I'm thinking of things like qGetTLSAddr here.  When GDB needs it, it
will try it.  If the program being debugged needs TLS, then the stub
supports an environment including TLS, and is likely to support
fetching the TLS addr.  On the other hand, if it doesn't, the user's
asked us to make a round trip to the stub and we've done so - it's
just that we came back with an error message.

For things like qOffsets, the story is a bit different.  That's
something we send unsolicited at connection, and it's not necessarily
fatal to what we're doing if it's missing.  So there's a clear
advantage in mentioning it - that's why I implemented qSupported
support for it as my example.

That's why I implemented an option to choose an intelligent default for
new packets.  If it's something that will show up in transcripts with
other stubs, and its loss is survivable, then requiring it to be
mentioned saves on roundtrips.

I intend to use the "only supported if mentioned" path ruthlessly for
new packets.  Let's see, queued up in various trees (and in various
states - don't bank on all these being submitted and useful):

  - A qOffsets replacement with a different reply format, designed for
    ELF segments rather than sections.  This is a startup packet,
    so the round trip is important.

  - The next generation of qPart:features.  Also a startup packet.

  - A "make the remote stub shut down" packet, useful in extended mode.
    There'd have to be a user command for this, so the round trip
    seems ignorable; if it fails, we'll let the user know.

  - Additional commands for running programs with arguments in extended
    mode and attaching to remote packets.  Again, only sent in response
    to user request, so if the stub doesn't support it, we can find out
    at that point.

The first two should definitely be assumed missing if they are not
supported.  The last two could be either.  We could set a policy that
says "we require use of qSupported for any new packets", though, and
that wouldn't hurt either.  Simply keep a list in the manual of which
are which, and save on "m+;M+;c+".

-- 
Daniel Jacobowitz
CodeSourcery