Tell remote stubs which signals are boring

> Date: Thu, 26 Oct 2006 08:18:39 -0400
> From: Daniel Jacobowitz <drowfalse.org>
> Cc: gdbsourceware.org, ddaneyavtrex.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 <drowfalse.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.