From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14758 invoked by alias); 26 Oct 2006 15:10:13 -0000 Received: (qmail 14748 invoked by uid 22791); 26 Oct 2006 15:10:12 -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; Thu, 26 Oct 2006 15:10:09 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Gd6rv-0000qi-0R; Thu, 26 Oct 2006 11:10:07 -0400 Date: Thu, 26 Oct 2006 15:10:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sourceware.org, ddaney@avtrex.com Subject: Re: [rfc/remote] Tell remote stubs which signals are boring Message-ID: <20061026151006.GA2954@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sourceware.org, ddaney@avtrex.com References: <20061025212441.GA622@nevyn.them.org> <453FEB98.8090202@avtrex.com> <20061026014027.GA9023@nevyn.them.org> <20061025212441.GA622@nevyn.them.org> <20061026121838.GA28927@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.13 (2006-08-11) 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-10/txt/msg00263.txt.bz2 On Thu, Oct 26, 2006 at 11:01:18AM -0400, Eli Zaretskii wrote: > > On Thu, Oct 26, 2006 at 02:57:29AM -0400, Eli Zaretskii wrote: > > > > Date: Wed, 25 Oct 2006 17:24:41 -0400 > > > > From: Daniel Jacobowitz > > > > > > > > This is the solution I came up with for that problem, adjusted to HEAD > > > > and given a more sensible packet name. I have a tested implementation > > > > of this patch for HEAD, if my remote protocol choices are acceptable. > > > > The new mechanism is completely transparent to the user. > > > > > > I'm confused: shouldn't this packet be automatically sent to a remote > > > target when I say, e.g., "handle SIGALRM nostop noprint pass"? Am I > > > missing something? > > > > Now I'm confused :-) Isn't that exactly what I said above? It's > > completely transparent; it just works. > > Perhaps I'm too dumb today, but ``completely transparent'' does not > tell me that there's any connection between `handle' and `set remote > pass-signals', especially since an interactive command can hardly be > described as ``transparent to the user''. It's transparent because you should never, ever have to use "set remote pass-signals". If the target reports that it supports QPassSignals, it will be used automatically. If it doesn't report it, then forcing it on isn't going to work, unless the remote target is buggy (supports the packet but claims not to). Disabling it is, again, not useful unless the remote target is buggy (supports the packet but mishandles it). This is one of the reasons I mentioned in another message yesterday that I was thinking of removing or moving to "maint" the various "set remote" packet controls - they're confusing. Best would probably be to both move and rename them: "set remote pass-signals-packet" would become "maint set remote QPassSignals", with a clear correspondence to the packet it controls. It's a design feature of the remote protocol that everything is autonegotiated, so (just as currently), these would all default to an "auto" setting. WDYT? -- Daniel Jacobowitz CodeSourcery