From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17881 invoked by alias); 26 Oct 2006 15:18:40 -0000 Received: (qmail 17870 invoked by uid 22791); 26 Oct 2006 15:18:39 -0000 X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (199.232.76.164) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Oct 2006 15:18:33 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.34) id 1Gd703-0007iG-IJ; Thu, 26 Oct 2006 11:18:31 -0400 From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb@sourceware.org, ddaney@avtrex.com In-reply-to: <20061026151006.GA2954@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 26 Oct 2006 11:10:06 -0400) Subject: Re: [rfc/remote] Tell remote stubs which signals are boring Reply-to: Eli Zaretskii 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> <20061026151006.GA2954@nevyn.them.org> Message-Id: Date: Thu, 26 Oct 2006 15:18:00 -0000 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/msg00264.txt.bz2 > Date: Thu, 26 Oct 2006 11:10:06 -0400 > From: Daniel Jacobowitz > Cc: gdb@sourceware.org, ddaney@avtrex.com > > 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 sounds like a good reason not to have the command at all. If we decide not to install that part of the patch, my request is a moot point, but as long as the command is described in the manual, please add the mutual cross-references between it and `handle'. > 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? Sounds convincing to me, assuming that auto-negotiated settings never lie about the support and seldom have bugs that make them not useful. I'm not in a position to say whether this is true, since I don't have enough experience with debugging remote targets.