This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Improve completion of locations
- To: Elena Zannoni <ezannoni at cygnus dot com>
- Subject: Re: [RFA] Improve completion of locations
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Date: Wed, 9 May 2001 13:48:02 +0300 (IDT)
- cc: gdb-patches at sources dot redhat dot com
On Tue, 8 May 2001, Elena Zannoni wrote:
> Eli, one minor problem with your patch is that your sources are not up
> to date. The #include of completer.h in tracepoint.c and infcmd.c was
> removed by JT on March 27. So you will have to add it back in when you
> commit the patch.
Okay, thanks for the heads-up.
> Using a gdb with your patch applied to debug another gdb I am getting
> something I don't understand:
>
> (top-gdb) b symtab.<TAB>
> Display all 10987 possibilities? (y or n)
>
> what is it trying to do (note the '.')?
Granted, I've bumped into this as well. The immediate problem here is
that Readline passes an empty string to our completion function,
because `.' is not a word-constituent character. The completer then
simply comes up with a list of all the symbols in the program.
I thought about writing special code for this specific case, which
would realize that this is a file name without an extension. However,
it isn't clear that this is the right thing to do, because the user
could well mean to write symtab.foobar, meaning the field foobar of
the struct named symtab. GDB has no simple way of knowing what case
it is faced with. Also, the symbol completion is not smart enough to
see if there is indeed a symbol named symtab, if it is a struct or a
class, and only list members of that struct after the dot.
When presented with the same input, the original completion would also
do the same, so this isn't a regression.
If you (or someone else) has suggestions how to improve this, I'd be
glad to hear them. But this would be an additional improvement.
> Using the ':' I get a list of completions which includes:
> (top-gdb) b symtab.c:
> __builtin_va_list int
> _initialize_symtab keep_going
> add_filename_to_list long double
> block_found long int
> block_function long long int
> bound long long unsigned int
> builtin_type_error long unsigned int
> char lookup_block_symbol
> completion_list_add_name lookup_partial_symbol
> complex double lookup_partial_symtab
> complex float lookup_symbol
> complex int lookup_symbol_aux
> complex long double lookup_symtab
> contained_in lookup_symtab_1
> cplusplus_hint lookup_transparent_type
> [...many more...]
>
> But why am I getting the types names, like 'char', 'long double', etc?
> They must be coming from the minsymbols, maybe.
I saw this, but my testing indicates that these symbols are indeed
inside the symtab for the file (symtab.c, in this case), not inside a
minsym. In fact, the function make_file_symbol_completion_list which
I added doesn't even look at minsyms. AFAIU, the symtab for a file
holds all the data types that were visible to the compiler when the
file was compiled. If you see something different, please tell,
perhaps there's a bug in my code.
> Do we want those? Probably not.
Probably, but not positively. Someone could type something like this:
(gdb) break symtab.c:*(long *)&foobar
> (top-gdb) b symtab
> symtab symtab.h symtab_fns symtab_to_filename
> symtab.c symtab_and_line symtab_symbol_info symtabs_and_lines
>
> (top-gdb) b symt<TAB>
> symtab symtab_and_line symtab_to_filename
> symtab.c symtab_fns symtabs_and_lines
> symtab.h symtab_symbol_info symtoken
>
> (top-gdb) b symtab.c:make_<TAB>
> make_cleanup_free_search_symbols make_symbol_completion_list
> make_file_symbol_completion_list make_symbol_overload_list
> make_source_files_completion_list
>
> These all seem to work now and didn't before, which is really neat.
>
> I think some more refinements are needed.
I'd be glad to make this more smart, but it's not simple. By far the
nastiest problem is that Readline decides what is the word which is
being completed on _before_ our completion function is called. This
defeats many nifty tricks we could do using the context of the
completion.
But I'm open to ideas which would make completion even more useful.
> Syntactically, there is a line I don't like :
>
> > + (*list)[*list_used += 1] = NULL;
>
> Could you just use '++'?
Yes; I will change that.
> Sorry, I don't have much more time right now to look at it in more
> detail. I think I am starting to understand this whole patch. I may
> have some more comments tomorrow.
Thanks.