From patchwork Fri Jul 19 19:43:31 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 33741 Received: (qmail 129646 invoked by alias); 19 Jul 2019 19:43:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 129637 invoked by uid 89); 19 Jul 2019 19:43:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_SHORT, KAM_STOCKGEN, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-wm1-f68.google.com Received: from mail-wm1-f68.google.com (HELO mail-wm1-f68.google.com) (209.85.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Jul 2019 19:43:36 +0000 Received: by mail-wm1-f68.google.com with SMTP id a15so29787761wmj.5 for ; Fri, 19 Jul 2019 12:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=me31UbOSt9TJSjvMQWV+PgBs9m3Rhllct3S+oIih8ZI=; b=J8XImx8RipvjP2tczqNMxFUUodrCVMPxf/RFHX9tKVoS5ihaAGvaBv7L3KedsVZJ7N clHBkuUnG9S0XZLGHf63EcyVpQmP9HKqgFCBQW2Q2XE3/QlTJ/f3HUnsQnwDYAH8aYcT G/w25DR0EZkULI9vjwPdH/JzZgwtRr7hPh230Lsay3MkkA3xdvSCgZvaR7ZnJVL32pyK OGSuipyUaghPZbbAlMFf/C/NOU2oJUp/iIutEO5nfCywiFEBgoBnJOM/mjW/QEAdus2r CC2DVUegb5dq9+4gxf08c/ZU5h12kpeEQtq8JgOVbGRqddzR3lJPRnDCKTIWaqozmJGT a4nA== Return-Path: Received: from localhost (host86-171-250-129.range86-171.btcentralplus.com. [86.171.250.129]) by smtp.gmail.com with ESMTPSA id v5sm34751877wre.50.2019.07.19.12.43.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 19 Jul 2019 12:43:32 -0700 (PDT) Date: Fri, 19 Jul 2019 20:43:31 +0100 From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Pedro Alves Subject: Re: [PATCH 2/3] gdb: Improve output from "info types" commad Message-ID: <20190719194331.GB23204@embecosm.com> References: <51913d3e-79a3-83a2-9e66-c4f62dd9feab@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51913d3e-79a3-83a2-9e66-c4f62dd9feab@redhat.com> X-Fortune: How come we never talk anymore? X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes * Pedro Alves [2019-07-18 21:07:10 +0100]: > On 7/12/19 12:37 PM, Andrew Burgess wrote: > > 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. > > > > That sounds fine to me. > > > * 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 mobed from... > > (_initialize_symtab): ... move and update FIXME comment to above. > > > > Typo: "mobed". > > > gdb/testsuite/ChangeLog: > > > > * gdb.base/info-types.c: New file. > > * gdb.base/info-types.exp: New file. > > * gdb.cp/info-types.cc: New file. > > * gdb.cp/info-types.exp: New file. > > I'm not immediately seeing what the C++ testcase is trying to > test. If you replace "class" with struct, and use "typedef struct AA" > instead of "typedef AA", isn't that code basically C code as well? > > Also, might it be a good idea to check the info-types.c stuff in > C++ mode as well, to make sure we normalize C and C++ modes? > I.e., make gdb.base/info-types.exp compile once as a C program, and > once as a C++ program? I've removed the gdb.cp/info-types.{cc,exp} files, and extended the gdb.base test to include an example of 'class'. Yes, we know internally they are handled just like structs, but I'd like to cover it "just in case". The gdb.base case is now compiled as C and C++. Thanks, Andrew --- 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. diff --git a/gdb/symtab.c b/gdb/symtab.c index 16861e2bc92..ba0d5eed6b3 100644 --- a/gdb/symtab.c +++ b/gdb/symtab.c @@ -4339,13 +4339,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; @@ -4628,7 +4628,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 @@ -6080,14 +6096,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\ diff --git a/gdb/testsuite/gdb.base/info-types.c b/gdb/testsuite/gdb.base/info-types.c new file mode 100644 index 00000000000..6746238801d --- /dev/null +++ b/gdb/testsuite/gdb.base/info-types.c @@ -0,0 +1,78 @@ +/* Copyright 2019 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +typedef int my_int_t; +typedef float my_float_t; +typedef my_int_t nested_int_t; +typedef my_float_t nested_float_t; + +struct baz_t +{ + float f; + double d; +}; + +typedef struct baz_t baz_t; +typedef struct baz_t baz; +typedef baz_t nested_baz_t; +typedef baz nested_baz; +typedef struct baz_t *baz_ptr; + +enum enum_t +{ + AA, BB, CC +}; + +typedef enum enum_t my_enum_t; +typedef my_enum_t nested_enum_t; + +volatile int var_a; +volatile float var_b; +volatile my_int_t var_c; +volatile my_float_t var_d; +volatile nested_int_t var_e; +volatile nested_float_t var_f; +volatile struct baz_t var_g; +volatile baz_t var_h; +volatile baz var_i; +volatile nested_baz_t var_j; +volatile nested_baz var_k; +volatile baz_ptr var_l; +volatile enum enum_t var_m; +volatile my_enum_t var_n; +volatile nested_enum_t var_o; + +#ifdef __cplusplus + +class CL +{ + int a; +}; + +typedef CL my_cl; +typedef CL *my_ptr; + +volatile CL var_cpp_a; +volatile my_cl var_cpp_b; +volatile my_ptr var_cpp_c; + +#endif /* __cplusplus */ + +int +main () +{ + asm ("" ::: "memory"); + return 0; +} diff --git a/gdb/testsuite/gdb.base/info-types.exp b/gdb/testsuite/gdb.base/info-types.exp new file mode 100644 index 00000000000..a5808425398 --- /dev/null +++ b/gdb/testsuite/gdb.base/info-types.exp @@ -0,0 +1,109 @@ +# Copyright 2019 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# Check that 'info types' produces the expected output for an inferior +# containing a number of different types. + +# Only test C++ if we are able. Always use C. +if { [skip_cplus_tests] || [get_compiler_info "c++"] } { + set lang {c} +} else { + set lang {c c++} +} + +foreach l $lang { + set dir "$l" + remote_exec host "rm -rf [standard_output_file ${dir}]" + remote_exec host "mkdir -p [standard_output_file ${dir}]" +} + +# Run 'info types' test, compiling the test file for language LANG, +# which should be either 'c' or 'c++'. +proc run_test { lang } { + global testfile + global srcfile + global binfile + global subdir + global srcdir + global compile_flags + + standard_testfile .c + + if {[prepare_for_testing "failed to prepare" \ + "${lang}/${testfile}" $srcfile "debug $lang"]} { + return -1 + } + + if ![runto_main] then { + fail "can't run to main" + return 0 + } + + if { $lang == "c++" } { + set output_re \ + [multi_line \ + "All defined types:" \ + "" \ + "File .*:" \ + "59:\[\t \]+CL;" \ + "21:\[\t \]+baz_t;" \ + "33:\[\t \]+enum_t;" \ + "28:\[\t \]+typedef baz_t baz;" \ + "31:\[\t \]+typedef baz_t \\* baz_ptr;" \ + "27:\[\t \]+typedef baz_t baz_t;" \ + "\[\t \]+double" \ + "\[\t \]+float" \ + "\[\t \]+int" \ + "64:\[\t \]+typedef CL my_cl;" \ + "38:\[\t \]+typedef enum_t my_enum_t;" \ + "17:\[\t \]+typedef float my_float_t;" \ + "16:\[\t \]+typedef int my_int_t;" \ + "65:\[\t \]+typedef CL \\* my_ptr;" \ + "30:\[\t \]+typedef baz_t nested_baz;" \ + "29:\[\t \]+typedef baz_t nested_baz_t;" \ + "39:\[\t \]+typedef enum_t nested_enum_t;" \ + "19:\[\t \]+typedef float nested_float_t;" \ + "18:\[\t \]+typedef int nested_int_t;" \ + "\[\t \]+unsigned int"] + } else { + set output_re \ + [multi_line \ + "All defined types:" \ + "" \ + "File .*:" \ + "28:\[\t \]+typedef struct baz_t baz;" \ + "31:\[\t \]+typedef struct baz_t \\* baz_ptr;" \ + "21:\[\t \]+struct baz_t;" \ + "\[\t \]+double" \ + "33:\[\t \]+enum enum_t;" \ + "\[\t \]+float" \ + "\[\t \]+int" \ + "38:\[\t \]+typedef enum enum_t my_enum_t;" \ + "17:\[\t \]+typedef float my_float_t;" \ + "16:\[\t \]+typedef int my_int_t;" \ + "30:\[\t \]+typedef struct baz_t nested_baz;" \ + "29:\[\t \]+typedef struct baz_t nested_baz_t;" \ + "39:\[\t \]+typedef enum enum_t nested_enum_t;" \ + "19:\[\t \]+typedef float nested_float_t;" \ + "18:\[\t \]+typedef int nested_int_t;" \ + "\[\t \]+unsigned int" ] + } + + gdb_test "info types" $output_re +} + +foreach_with_prefix l $lang { + run_test $l +}