From: Mike Frysinger <vapier@gentoo.org>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch v2] gdb: add completion handler for "handle"
Date: Thu, 02 Aug 2012 15:35:00 -0000 [thread overview]
Message-ID: <201208021134.51757.vapier@gentoo.org> (raw)
In-Reply-To: <501A6357.4070503@redhat.com>
[-- Attachment #1: Type: Text/Plain, Size: 3579 bytes --]
On Thursday 02 August 2012 07:24:07 Pedro Alves wrote:
> On 08/02/2012 04:58 AM, Mike Frysinger wrote:
> > +VEC (char_ptr) *
> > +string_array_completer (struct cmd_list_element *ignore,
> > + char *text, char *word, const char * const strings[],
> > + size_t num_strings)
> > +{
> > + size_t i;
> > + VEC (char_ptr) *return_val = NULL;
> > + size_t len = strlen (word);
> > +
> > + for (i = 0; i < num_strings; ++i)
> > + {
> > + if (strncasecmp (strings[i], word, len) == 0)
> > + VEC_safe_push (char_ptr, return_val, xstrdup (strings[i]));
> > + }
> > +
> > + return return_val;
> > +}
>
> See complete_on_enum.
hrm, i was only looking in completer.h. i don't suppose there's a central
place for these APIs ? or is that expecting too much ? ;)
also, i think this function is broken. when i try to call it, i have:
text = "SIGINT a"
word = "a"
instead of completing "a" into "all", it tries to complete "SIGINT a" and so
returns no matches. i'd have to lie and pass it (word, word) instead of
(text, word) ...
> > +/* Complete the "handle" command. */
> > +
> > +static VEC (char_ptr) *
> > +handle_completer (struct cmd_list_element *ignore,
> > + char *text, char *word)
> > +{
> > + /* First word is a signal, while the rest are keywords. */
>
> Actually, "handle" accepts more than one signal. E.g.,
ok, but that's not what the documentation says:
http://sourceware.org/gdb/current/onlinedocs/gdb/Signals.html
handle signal [keywords...]
Change the way gdb handles signal signal. signal can be the number of a
signal or its name (with or without the `SIG' at the beginning); a list of
signal numbers of the form `low-high'; or the word `all', meaning all the
known signals. Optional arguments keywords, described below, say what change
to make.
guess that needs updating too
> (gdb) handle SIGCANCEL SIGABRT stop
> Signal Stop Print Pass to program Description
> SIGABRT Yes Yes Yes Aborted
> SIGCANCEL Yes Yes Yes LWP internal signal
>
> Can we make that work? Basically, for all but the first arg, you'd
> accept the union of the signal names, and the possible actions.
is there a VEC_safe_merge helper ? i didn't see anything in common/vec.h. if
there was, then it should be easy to make this work.
> > - add_com ("handle", class_run, handle_command, _("\
> > -Specify how to handle a signal.\n\
> > + c = add_com ("handle", class_run, handle_command, _("\
> > +Handle signals: handle SIGNAL [KEYWORDS]\n\
> >
> > Args are signals and actions to apply to those signals.\n\
>
> The first line of the doc is special. It's what "apropos" shows.
ok ...
> before:
> (gdb) apropos signals
> handle -- Specify how to handle a signal
> info handle -- What debugger does when program gets various signals
> info signals -- What debugger does when program gets various signals
>
> after:
> (gdb) apropos signals
> handle -- Handle signals: handle SIGNAL [KEYWORDS]
> info handle -- What debugger does when program gets various signals
> info signals -- What debugger does when program gets various signals
>
> The old strings looked better here to me.
it does. i was just trying to improve the `help handle` output since it (plus
`help signal`) suck atm. it's really information dense and hard to pick out
anything quickly.
> This and the "signal" docu change are a bit of a tangent wrt completion,
> so split them out, please.
np
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-08-02 15:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-02 3:54 [patch] " Mike Frysinger
2012-08-02 3:58 ` [patch v2] " Mike Frysinger
2012-08-02 9:38 ` Yao Qi
2012-08-02 11:24 ` Pedro Alves
2012-08-02 15:35 ` Mike Frysinger [this message]
2012-08-02 16:24 ` Pedro Alves
2012-08-09 20:34 ` Tom Tromey
2012-08-09 20:46 ` Mike Frysinger
2012-08-03 3:51 ` [patch v3] " Mike Frysinger
2012-08-09 20:32 ` Tom Tromey
2012-08-10 5:03 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201208021134.51757.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox