diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2019-07-09 18:05:59 +0100 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2019-07-22 10:43:02 +0100 |
commit | eb86c5e2e824787875187901b12fba52ef873278 (patch) | |
tree | e487127c6778dc3e325acb0d882552e46a2610ae /gdb/symtab.c | |
parent | a8eab7c6d529ddd248ff5243bb22e9346196e376 (diff) | |
download | gdb-eb86c5e2e824787875187901b12fba52ef873278.zip gdb-eb86c5e2e824787875187901b12fba52ef873278.tar.gz gdb-eb86c5e2e824787875187901b12fba52ef873278.tar.bz2 |
gdb: Improve output from "info types" commad
This commit makes two changes to the "info types" command:
First, only use typedef_print for printing typedefs, and use
type_print for printing non-typedef scalar (non-struct) types. The
result of this is the output for builtin types goes from this:
typedef double;
typedef float;
typedef int;
to this:
double;
float;
int;
which seems to make more sense.
Next GDB no longer matches msymbols as possible type names. When
looking for function symbols it makes sense to report matching
msymbols from the text sections, and for variables msymbols from the
data/bss sections, but when reporting types GDB would match msymbols
of type absolute. But I don't see why these are likely to indicate
type names. As such I've updated the msymbol matching lists in
symtab.c:search_symbols so that when searching in the TYPES_DOMAIN, we
never match any msymbols.
gdb/ChangeLog:
* symtab.c (search_symbols): Adjust msymbol matching type arrays
so that GDB doesn't match any msymbols when searching in the
TYPES_DOMAIN.
(print_symbol_info): Print using typedef_print or type_print based
on the type of the symbol. Add updated FIXME comment moved from...
(_initialize_symtab): ... move and update FIXME comment to above.
gdb/testsuite/ChangeLog:
* gdb.base/info-types.c: New file.
* gdb.base/info-types.exp: New file.
Diffstat (limited to 'gdb/symtab.c')
-rw-r--r-- | gdb/symtab.c | 34 |
1 files changed, 21 insertions, 13 deletions
diff --git a/gdb/symtab.c b/gdb/symtab.c index ea2b813..5b8bfc1 100644 --- a/gdb/symtab.c +++ b/gdb/symtab.c @@ -4343,13 +4343,13 @@ search_symbols (const char *regexp, enum search_domain kind, struct symbol *sym; int found_misc = 0; static const enum minimal_symbol_type types[] - = {mst_data, mst_text, mst_abs}; + = {mst_data, mst_text, mst_unknown}; static const enum minimal_symbol_type types2[] - = {mst_bss, mst_file_text, mst_abs}; + = {mst_bss, mst_file_text, mst_unknown}; static const enum minimal_symbol_type types3[] - = {mst_file_data, mst_solib_trampoline, mst_abs}; + = {mst_file_data, mst_solib_trampoline, mst_unknown}; static const enum minimal_symbol_type types4[] - = {mst_file_bss, mst_text_gnu_ifunc, mst_abs}; + = {mst_file_bss, mst_text_gnu_ifunc, mst_unknown}; enum minimal_symbol_type ourtype; enum minimal_symbol_type ourtype2; enum minimal_symbol_type ourtype3; @@ -4632,7 +4632,23 @@ print_symbol_info (enum search_domain kind, /* Typedef that is not a C++ class. */ if (kind == TYPES_DOMAIN && SYMBOL_DOMAIN (sym) != STRUCT_DOMAIN) - typedef_print (SYMBOL_TYPE (sym), sym, gdb_stdout); + { + /* FIXME: For C (and C++) we end up with a difference in output here + between how a typedef is printed, and non-typedefs are printed. + The TYPEDEF_PRINT code places a ";" at the end in an attempt to + appear C-like, while TYPE_PRINT doesn't. + + For the struct printing case below, things are worse, we force + printing of the ";" in this function, which is going to be wrong + for languages that don't require a ";" between statements. */ + if (TYPE_CODE (SYMBOL_TYPE (sym)) == TYPE_CODE_TYPEDEF) + typedef_print (SYMBOL_TYPE (sym), sym, gdb_stdout); + else + { + type_print (SYMBOL_TYPE (sym), "", gdb_stdout, -1); + printf_filtered ("\n"); + } + } /* variable, func, or typedef-that-is-c++-class. */ else if (kind < TYPES_DOMAIN || (kind == TYPES_DOMAIN @@ -6084,14 +6100,6 @@ Prints the functions.\n"), _("functions"))); set_cmd_completer_handle_brkchars (c, info_print_command_completer); - /* FIXME: This command has at least the following problems: - 1. It prints builtin types (in a very strange and confusing fashion). - 2. It doesn't print right, e.g. with - typedef struct foo *FOO - type_print prints "FOO" when we want to make it (in this situation) - print "struct foo *". - I also think "ptype" or "whatis" is more likely to be useful (but if - there is much disagreement "info types" can be fixed). */ c = add_info ("types", info_types_command, _("\ All type names, or those matching REGEXP.\n\ Usage: info types [-q] [REGEXP]\n\ |