From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10572 invoked by alias); 10 May 2006 22:55:00 -0000 Received: (qmail 10561 invoked by uid 22791); 10 May 2006 22:54:59 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 10 May 2006 22:54:53 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FdxZz-0005GO-MP for gdb@sourceware.org; Wed, 10 May 2006 18:54:51 -0400 Date: Thu, 11 May 2006 02:26:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: [PROPOSAL] Checking for supported packets - revised Message-ID: <20060510225451.GA19844@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20060314021526.GA802@nevyn.them.org> <20060321051221.GA15578@nevyn.them.org> <20060330215247.GA9062@nevyn.them.org> <20060331135859.GA27522@nevyn.them.org> <20060331141958.GA28073@nevyn.them.org> <20060509230123.GA19291@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00116.txt.bz2 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