This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [rfc/remote] Tell remote stubs which signals are boring
> 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.