Re: [PATCH 3/3] gdb/mi: Add new commands -symbol-info-{functions,variables,types}

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Simon Marchi <simark@simark.ca> [2019-10-03 23:01:12 -0400]:

> On 2019-09-26 7:09 p.m., Andrew Burgess wrote:
> > Add new MI commands -symbol-info-functions, -symbol-info-variables,
> > and -symbol-info-types which correspond to the CLI commands 'info
> > functions', 'info variables', and 'info types' respectively.
> 
> Hi Andrew,
> 
> The first thing I tried was to run it on GDB itself and run "-symbol-info-functions"
> by itself.  Apparently, it tries to list all functions in the program :).  I think
> we need to be careful with that, as it would be really easy for a debug session to
> become unresponsive.  Imagine an IDE that has a little box to search symbols by name.
> The user while debugging a big program, types "e<enter>", which generates this
> MI command:
> 
>   -symbol-info-functions --name "e"
> 
> This would essentially hang the debug session while GDB expands all the symtabs with
> at least a function with "e" in its name.  It would take a huge amount of time and
> memory.  I don't know how easy it would be to implement, but for these cases, a
> "--max-results N" switch, which would stop the search early, might useful.

I looked into how easy this would be to implement, and I'm worried it
might be a rather involved task.

symtab.c:search_symbols is where the limit logic would need to be
applied, the problem is the logic in that function seems to basically
go like this:

   (1) Expand all symtabs that have a matching filename, and which
   contain a symbol that matches the regexp - this will be all symtabs
   in your worst case scenario.  At this point we expand only, symbols
   are not added to the result list.

   (2) Expand symtabs for msymbols with a matching name, again this is
   all msymbols in your worst case scenario, and again we don't add to
   the results list at this point.

   (3) Search through all symtabs adding matching symbols to the
   result list.

   (4) Sort the result list, and remove duplicates.

   (5) Add matching msymbols to the results list.

The problem I see here is that steps (1) and (2) are the costly parts
we would like to limit, however its not until steps (3) and (5) that
we really know how many results we've collected so far.

I'm going to experiment to see if I can find a way to build the
results as we process each objfile / symbtab, but I suspect doing that
might require some significant work.  If you have any suggestions then
I'm happy to listen.

One idea I did have, which isn't exactly a solution, but might be
related would be adding a timeout to the MI command.  This would
basically be like the user sending Ctrl-C after a given time.  You
still wouldn't get partial results, you'd just see that the command
was aborted due to timeout - however, this might provide a nice safety
net for MI commands.

Any suggestions welcome.

Thanks,
Andrew

> 
> Note that the same happens if you type "info functions" in the CLI.  But at least,
> when using the CLI interactively, you can ctrl-C, which front-ends don't typically
> do.
> 
> Also, since this output is meant to be consumed by a front-end, it would be
> interesting to have the details of the symbols in separate fields.  For example,
> for variables, have the type and name in separate fields.  This gives front-ends
> more freedom on how to display them.
> 
> For functions, I would even see (maybe not in this patch though) a list of parameters
> with their names and types.
> 
> Of course, we can always start with something basic and add fields as we go.
> 
> I didn't really look at the implementation, since it's getting a bit late, but:
> 
> > diff --git a/gdb/mi/mi-cmds.h b/gdb/mi/mi-cmds.h
> > index 91ce4cd4070..5fa4fafbb05 100644
> > --- a/gdb/mi/mi-cmds.h
> > +++ b/gdb/mi/mi-cmds.h
> > @@ -94,6 +94,9 @@ extern mi_cmd_argv_ftype mi_cmd_stack_list_locals;
> >  extern mi_cmd_argv_ftype mi_cmd_stack_list_variables;
> >  extern mi_cmd_argv_ftype mi_cmd_stack_select_frame;
> >  extern mi_cmd_argv_ftype mi_cmd_symbol_list_lines;
> > +extern mi_cmd_argv_ftype mi_cmd_symbol_info_functions;
> > +extern mi_cmd_argv_ftype mi_cmd_symbol_info_variables;
> > +extern mi_cmd_argv_ftype mi_cmd_symbol_info_types;
> 
> The last two are not in alphabetical order (in the .c as well).
> 
> Simon