Tell remote stubs which signals are boring

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