This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]