Re: [patch v2] gdb: add completion handler for "handle"

Mike Frysinger
2012-08-02T15:35:07Z

[-- 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 --]