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

[Eli Zaretskii <eliz@gnu.org>]

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