From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24161 invoked by alias); 23 Aug 2012 11:11:54 -0000 Received: (qmail 24147 invoked by uid 22791); 23 Aug 2012 11:11:53 -0000 X-SWARE-Spam-Status: No, hits=-7.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Aug 2012 11:11:39 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7NBBbsn027358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Aug 2012 07:11:37 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q7NBBZhE017396; Thu, 23 Aug 2012 07:11:36 -0400 Message-ID: <50360FE7.4060704@redhat.com> Date: Thu, 23 Aug 2012 11:11:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Doug Evans CC: Mike Frysinger , gdb-patches@sourceware.org Subject: Re: [PATCH v2] gdb: improve usage strings References: <1344704080-24677-1-git-send-email-vapier@gentoo.org> <1344823549-24684-1-git-send-email-vapier@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00653.txt.bz2 On 08/13/2012 09:28 PM, Doug Evans wrote: > On Sun, Aug 12, 2012 at 7:05 PM, Mike Frysinger wrote: >> c = add_com ("signal", class_run, signal_command, _("\ >> -Continue program giving it signal specified by the argument.\n\ >> -An argument of \"0\" means continue program without giving it a signal.")); >> +Continue program and simultaneously send it the specified signal.\n\ >> +Usage: signal SIGNAL\n\ >> +An argument of \"0\" means continue the program without sending it a signal.")); >> set_cmd_completer (c, signal_completer); > > That's ok I guess. How about "Continue program with the specified signal." ? Agreed. I was catching on up the thread, and thought of suggest this. I could swear that's terminology we already use. Ah, at least here: ... @item C @var{sig}@r{[};@var{addr}@r{]} @cindex @samp{C} packet Continue with signal @var{sig} (hex signal number). If ^^^^^^^^^^^^^^^^^^^^ @samp{;@var{addr}} is omitted, resume at same address. ... You can also use the @code{signal} command to prevent your program from seeing a signal, or cause it to see a signal it normally would not see, or to give it any signal at any time. For example, if your program stopped due to some sort of memory reference error, you might store correct values into the erroneous variables and continue, hoping to see more execution; but your program would probably terminate immediately as a result of the fatal signal once it saw the signal. To prevent this, you can continue with @samp{signal 0}. @xref{Signaling, ,Giving your ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Program a Signal}. ... Consistency between help and manual is good. > > Also, it would be good to augment the docs for "sig 0" to denote it > can be used to resume a program and discard the signal that is pending > for it, and would otherwise receive if you did a "continue". It's > kinda implicit in the existing wording, but I've seen a few cases > where more clarity would have helped. > > How about: > > An argument of "0" means continue the program without sending it a signal. > This is useful in cases where the program stopped because of a signal, > and you want to resume the program and discard the signal. -- Pedro Alves