From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18442 invoked by alias); 12 May 2006 13:24:55 -0000 Received: (qmail 18433 invoked by uid 22791); 12 May 2006 13:24:54 -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, 12 May 2006 13:24:52 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FeXdS-0001R8-D6 for gdb@sourceware.org; Fri, 12 May 2006 09:24:50 -0400 Date: Fri, 12 May 2006 13:55:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: [PROPOSAL] Checking for supported packets - revised Message-ID: <20060512132450.GA4925@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <20060330215247.GA9062@nevyn.them.org> <20060331135859.GA27522@nevyn.them.org> <20060331141958.GA28073@nevyn.them.org> <20060509230123.GA19291@nevyn.them.org> <20060510225451.GA19844@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/msg00164.txt.bz2 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