From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16325 invoked by alias); 11 May 2006 00:19:32 -0000 Received: (qmail 16317 invoked by uid 22791); 11 May 2006 00:19:31 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 May 2006 00:19:30 +0000 Received: (qmail 23083 invoked from network); 11 May 2006 00:19:28 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 May 2006 00:19:28 -0000 To: gdb@sourceware.org Subject: Re: [PROPOSAL] Checking for supported packets - revised 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> <20060510225451.GA19844@nevyn.them.org> From: Jim Blandy Date: Thu, 11 May 2006 02:36:00 -0000 In-Reply-To: <20060510225451.GA19844@nevyn.them.org> (Daniel Jacobowitz's message of "Wed, 10 May 2006 18:54:51 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00117.txt.bz2 Daniel Jacobowitz 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! :)