From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3514 invoked by alias); 26 Oct 2006 15:01:36 -0000 Received: (qmail 3506 invoked by uid 22791); 26 Oct 2006 15:01:35 -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:01:26 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.34) id 1Gd6jO-0005ct-3M; Thu, 26 Oct 2006 11:01:20 -0400 From: Eli Zaretskii To: Daniel Jacobowitz CC: gdb@sourceware.org, ddaney@avtrex.com In-reply-to: <20061026121838.GA28927@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 26 Oct 2006 08:18:39 -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> Message-Id: Date: Thu, 26 Oct 2006 15:01: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/msg00262.txt.bz2 > Date: Thu, 26 Oct 2006 08:18:39 -0400 > From: Daniel Jacobowitz > Cc: gdb@sourceware.org, ddaney@avtrex.com > > 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''. > > Then this should be mentioned in the manual, both where the new packet > > and command are described, and where the "handle" command is > > described. > > Can you expand on this? > > Honestly, I have no idea what to say. It's just a performance > optimization; it shouldn't affect the user experience at all. We are talking about 2 user commands which are related. That relation should be mentioned in the manual. Without that, a user could turn off the new packet and not understand that this could do harm when the inferior uses signals. Here's another way to look at the issue: suppose this patch is already in GDB, and suppose you are J. Random Hacker who experiences the problem that originally caused you to write the patch--how would you know to toggle `set remote pass-signals' to try to see if that is the cause of your trouble? I think, if the description of `handle' has an xref to the description of `set remote pass-signals', you'd find that info much quicker and more reliably. If this is still unclear, I'll fix it myself once it's in CVS, and post the patch here in the hope that it'd be clear then.