Re: [PROPOSAL] Checking for supported packets - revised

[Jim Blandy <jimb at codesourcery dot com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Wed, May 10, 2006 at 03:15:17PM -0700, Jim Blandy wrote:
>> 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.

Assuming packets are more often added than deleted, it doesn't seem
like a maintenance problem to me: any mistakes will get caught
quickly; you can't test the packet without fixing them.

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

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! :)