From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4528 invoked by alias); 26 May 2006 18:42:28 -0000 Received: (qmail 4518 invoked by uid 22791); 26 May 2006 18:42:27 -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; Fri, 26 May 2006 18:42:24 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FjhGQ-0001cA-D0 for gdb@sourceware.org; Fri, 26 May 2006 14:42:22 -0400 Date: Fri, 26 May 2006 22:12:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Take three: [PROPOSAL] Checking for supported packets Message-ID: <20060526184222.GA5895@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20060331135859.GA27522@nevyn.them.org> <20060331141958.GA28073@nevyn.them.org> <20060509230123.GA19291@nevyn.them.org> <20060510225451.GA19844@nevyn.them.org> <20060512132450.GA4925@nevyn.them.org> <20060523183155.GA357@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060523183155.GA357@nevyn.them.org> User-Agent: Mutt/1.5.11+cvs20060403 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/msg00374.txt.bz2 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. Reply: `STUBFEATURE [;STUBFEATURE]...' 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: `NAME=VALUE' 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. `NAME+' The remote protocol feature NAME is supported, and does not need an associated value. `NAME-' The remote protocol feature NAME is not supported. `NAME?' 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 targets. These are the currently defined stub features and their properties: Packet Name Value Default Probe Allowed Required `PacketSize' Yes `-' No `qXfer:features' No `-' Yes These are the currently defined stub features, in more detail: `PacketSize=BYTES' 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. `qXfer:features' The remote stub can respond to the the `qXfer:features' query (*note `qXfer:features': qXfer features.). -- Daniel Jacobowitz CodeSourcery