Re: [rfc/remote] Tell remote stubs which signals are boring

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 26 Oct 2006 08:18:39 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 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 <drow@false.org>
> > > 
> > > 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.