Re: [PROPOSAL] Checking for supported packets - revised

[Daniel Jacobowitz <drow at false dot org>]

On Wed, May 10, 2006 at 05:19:28PM -0700, Jim Blandy wrote:
> Okay --- I hadn't thought of making that distinction.  If we go that
> way, then the protocol documentation should also explain how to decide
> whether to make GDB treat a new packet as "only supported if
> mentioned" or "try if unmentioned".  Having the rule in your head
> alone is no good! :)

I certainly meant to document this intention; if it was lacking, I'll
fix it.

I've been having second thoughts about the scheme.  When I showed this
to Sandra (one of our coworkers at CodeSourcery, for those reading
along) her primary reaction was that it was too complicated - too
many cases.  Here's a definition with the minimal number of cases
that I can manage:

- If your stub responds to qSupported, the response must include
  every packet it supports.
- If your stub does not respond to qSupported, every packet is
  probed.

I don't think that one is usable, because of the widespread existance
of stubs which don't know about packets we haven't invented yet -
they'd still have startup time grow with time.  The next step up the
complexity ladder is:

- If your stub responds to qSupported, the response must include
  every packet it supports.
- If your stub does not respond to qSupported, only a fixed list
  of packets will be used or probed for.  So 'qOffsets' will still
  be tried, but the new qFooBaz (added after qSupported) will be
  assumed missing.

The next step is what I posted:

- qSupported can report present or absent packets.
- Some packets must be mentioned in order to be supported.  Others
  will be probed for if not mentioned.
- If your stub does not respond to qSupported, only a fixed list
  of packets will be used or probed for.

So which of these is best?

The qSupported response for gdbserver would currently be on the order
of 200 bytes if all packets were mentioned.  It'll grow with time, too;
the more complex a stub, the larger a qSupported response it will have
to send.  I can easily envision one getting up to 400-500 bytes.
That's not too bad, even over an extremely slow link, but it's more
bytes than the current startup probing overhead by far.

If only some packets are required to be mentioned in qSupported rather
than all, along the lines of my previous message, then the size of the
qSupported response will still grow, but more slowly.  And the total
size of the packet will be much smaller as things like "g" and "Hc" are
omitted.

The tradeoff is in the complexity of the documentation; hopefully
a sufficiently clear manual will mitigate that, and some of the
clarifications that I added to this posting did in fact reassure
Sandra that it would be manageable for stub implementors.

I think a blurb up front of the remote protocol chapter referring to
this where it talks about packets which must be implemented would help.
(And what's there is quite bogus at the moment anyway.)

-- 
Daniel Jacobowitz
CodeSourcery