From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28857 invoked by alias); 7 Sep 2018 14:50:23 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 28842 invoked by uid 89); 7 Sep 2018 14:50:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=whatis, H*UA:1.0, cb_data, meaningful X-HELO: mailout02.webmailer.hosteurope.de Received: from mailout02.webmailer.hosteurope.de (HELO mailout02.webmailer.hosteurope.de) (80.237.138.58) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Sep 2018 14:50:20 +0000 Received: from server06.webmailer.hosteurope.de ([10.9.0.185])AUTHED by mailout.webmailer.hosteurope.de (mailout02.webmailer.hosteurope.de) running EXperimental Internet Mailer with esmtps (TLSv1:AES256-SHA:256) id 1fyI5R-0002sw-0O; Fri, 07 Sep 2018 16:50:17 +0200 Received: from nobody by server06.webmailer.hosteurope.de with local (Exim 4.72) (envelope-from ) id 1fyI5Q-0003EO-So; Fri, 07 Sep 2018 16:50:16 +0200 X-Squirrel-UserHash: EhVcX1dJRwNeRwQRAQsKVxc= X-Squirrel-FromHash: XAdeV10STQs= Message-ID: <244d2f88027af80aae3812b0597e8c19-EhVcX1dJRwNeRwQRAQsKVxcwfgFLV15YQUBGAEFbWkA3VF0NQVpwH1FRQ15cRioDWllfQ1tUUAlZ-webmailer1@server06.webmailer.hosteurope.de> In-Reply-To: <920a0f43-7ccf-5805-61d7-7fb645d4fbb3@ericsson.com> References: <8d8b95e9218d09f8d808936b4a9f163e-EhVcX1dJRwNeRwQRAQsKVxcwfgFLV15YQUBGAEFbWkA3VF0NQVpwH1FRQ15bQyoDWllYRVlWWQ1e-webmailer1@server03.webmailer.hosteurope.de> <920a0f43-7ccf-5805-61d7-7fb645d4fbb3@ericsson.com> Date: Fri, 07 Sep 2018 14:50:00 -0000 Subject: Re: MI: -var-create does not resolve typedefs From: "Martin Richtarsky" To: gdb@sourceware.org, simon.marchi@ericsson.com User-Agent: Host Europe Webmailer/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Status: not scanned, license restriction X-KLMS-AntiPhishing: not scanned, license restriction X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2018/09/07 08:55:00 #8682191; khse: 2015-01-01 01:01:01 X-KLMS-AntiVirus-Status: Clean, skipped X-HE-Access: Yes X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00014.txt.bz2 Simon Marchi schrieb: > On 2018-07-13 04:19 PM, Martin Richtarsky wrote: >> Hi, >> >> the result of the -var-create command is documented here [1] as follows: >> >> 'type' >> >> The varobj's type. This is a string representation of the type, as >> would be printed by the GDB CLI. >> >> However, for a typedef this does not seem to hold: >> >> $ cat mi.cpp >> #include >> #include >> >> typedef std::vector StringVec; >> typedef int MyInt; >> >> int main() >> { >> size_t a = 0; >> StringVec sv; >> MyInt i; >> return 0; >> } >> >> $ g++ -g2 mi.cpp >> $ gdb --interpreter=mi a.out >> ... >> 1-var-create - * "a" >> 1^done,name="var1",numchild="0",value="4195792",type="size_t",thread-id="1",has_more="0" >> (gdb) >> 2-var-create - * "sv" >> 2^done,name="var2",numchild="1",value="{...}",type="StringVec",thread-id="1",has_more="0" >> (gdb) >> ptype(a) >> &"ptype(a)\n" >> ~"type = unsigned long\n" >> ^done >> (gdb) >> ptype(sv) >> &"ptype(sv)\n" >> ~"type = class std::vector> std::char_traits, >> std::allocator >, std::allocator> std::char_traits, std::allocator > > > [with _Tp = >> std::basic_string, std::allocator >, >> _Alloc = std::allocator, >> std::allocator > >] : protected std::_Vector_base<_Tp, _Alloc> >> {\n" >> ~" public:\n" >> >> >> Note how ptype resolves the typedef, but -var-create just shows the >> alias. >> >> The issue can be solved by a simple patch: >> >> --- a/gdb/varobj-orig.c >> +++ b/gdb/varobj.c >> @@ -905,7 +905,7 @@ varobj_get_type (struct varobj *var) >> if (CPLUS_FAKE_CHILD (var) || !var->root->is_valid) >> return std::string (); >> >> - return type_to_string (var->type); >> + return type_to_string (check_typedef(var->type)); >> } >> >> /* Obtain the type of an object variable. */ >> >> >> This would also solve the issue I'm having when using MI with a split >> dwarf build and a gold index [2] >> >> Is this a bug or is the typedef intentionally not resolved? >> >> [1] >> https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Variable-Objects.html >> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23042 >> >> Best regards, >> Martin >> > > Hi Martin, > > I think it's on purpose that it gives the original type representation, as > used > in the code. That type is going to end up in the "variables" view of the > various > frontends. The type name as used in the code is more meaningful to the > user than > the possibly complex resolved type. > > Also, it's always possible for the frontend to ask GDB to resolve the > typedef, but > it's not possible to go back. So resolving the typedef right away would > loose some > important information. If people think it would be useful, it would > probably be > possible to add a "resolved_type" field to the -var-create response. > That's not > really what you are after though I believe. > > As mentioned in the doc [1], ptype's goal is to resolve typedefs, whereas > whatis does > not. I don't see any reason why -var-create should follow ptype's > behavior specifically. > > Simon > > [1] https://sourceware.org/gdb/onlinedocs/gdb/Symbols.html Hi Simon, thanks for the response. I can understand why that behavior makes sense. However, I don't understand the implementation in gdb. A bit of background: I have a rather large application (many TUs) that is built with -gsplit-dwarf. When running a whatis on e.g. a size_t variable, it is very slow. gdb is stuck in such a callstack: [1] So replace_typedefs() is called although typedefs are not supposed to be resolved. Basically the type is available already in c_type_print_base_1() before the call to print_name_maybe_canonical() and even earlier. (gdb) p type->main_type->name $9 = 0x15b2dd0 "size_t" Would it possible to change this? It would speed up debugging interaction tremendously. Or is the typedef resolution necessary for something I'm missing? [1] (gdb) bt #0 0x00007f2a7ee75aba in __strcmp_sse2_unaligned () from /lib64/libc.so.6 #1 0x00000000006f0ad0 in key_compare (key=0x7ffe2ecfa100, name=0xb25f65b0 "_POSIX2_CHAR_TERM", file=0xbee95e50, line=177) at /h/sources/gdb-8.1/gdb/macrotab.c:323 #2 0x00000000006f0b41 in macro_tree_compare (untyped_key1=140729683779840, untyped_key2=3202971264) at /h/sources/gdb-8.1/gdb/macrotab.c:342 #3 0x000000000098aa81 in splay_tree_splay (sp=0xbddec760, key=140729683779840) at /h/sources/gdb-8.1/libiberty/splay-tree.c:148 #4 0x000000000098b1b9 in splay_tree_lookup (sp=0xbddec760, key=140729683779840) at /h/sources/gdb-8.1/libiberty/splay-tree.c:455 #5 0x00000000006f12b3 in find_definition (name=0x44fdd730 "STDIN_FILENO", file=0xbee956b0, line=211) at /h/sources/gdb-8.1/gdb/macrotab.c:642 #6 0x00000000006f138e in check_for_redefinition (source=0xbee956b0, line=211, name=0x44fdd730 "STDIN_FILENO", kind=macro_object_like, argc=0, argv=0x0, replacement=0x7f2a011cf03a "0") at /h/sources/gdb-8.1/gdb/macrotab.c:693 #7 0x00000000006f1579 in macro_define_object_internal (source=0xbee956b0, line=211, name=0x44fdd730 "STDIN_FILENO", replacement=0x7f2a011cf03a "0", kind=macro_ordinary) at /h/sources/gdb-8.1/gdb/macrotab.c:763 #8 0x00000000006f1641 in macro_define_object (source=0xbee956b0, line=211, name=0x44fdd730 "STDIN_FILENO", replacement=0x7f2a011cf03a "0") at /h/sources/gdb-8.1/gdb/macrotab.c:788 #9 0x0000000000641945 in parse_macro_definition (file=0xbee956b0, line=211, body=0x7f2a011cf02d "STDIN_FILENO 0") at /h/sources/gdb-8.1/gdb/dwarf2read.c:23876 #10 0x0000000000642463 in dwarf_decode_macro_bytes (abfd=0x18e9530, mac_ptr=0x7f2a0004e6cc "\005\324\001\363\001\002", mac_end=0x7f2a000a8497 "", current_file=0xbee956b0, lh=0x39816c70, section=0x3387f3e0, section_is_gnu=1, section_is_dwz=0, offset_size=4, include_hash=0xaa35ef10) at /h/sources/gdb-8.1/gdb/dwarf2read.c:24275 #11 0x000000000064285a in dwarf_decode_macro_bytes (abfd=0x18e9530, mac_ptr=0x7f29fffd2794 "\003\343\001\002\a\314\230\a", mac_end=0x7f2a000a8497 "", current_file=0xbee956b0, lh=0x39816c70, section=0x3387f3e0, section_is_gnu=1, section_is_dwz=0, offset_size=4, include_hash=0xaa35ef10) at /h/sources/gdb-8.1/gdb/dwarf2read.c:24398 #12 0x000000000064285a in dwarf_decode_macro_bytes (abfd=0x18e9530, mac_ptr=0x7f29fffd4782 "\003\215\001/\a", mac_end=0x7f2a000a8497 "", current_file=0xbea8d530, lh=0x39816c70, section=0x3387f3e0, section_is_gnu=1, section_is_dwz=0, offset_size=4, include_hash=0xaa35ef10) at /h/sources/gdb-8.1/gdb/dwarf2read.c:24398 #13 0x0000000000642e03 in dwarf_decode_macros (cu=0xaf6d0f10, offset=8572, section_is_gnu=1) at /h/sources/gdb-8.1/gdb/dwarf2read.c:24623 #14 0x0000000000623479 in read_file_scope (die=0xaf8f5760, cu=0xaf6d0f10) at /h/sources/gdb-8.1/gdb/dwarf2read.c:11614 #15 0x0000000000621355 in process_die (die=0xaf8f5760, cu=0xaf6d0f10) at /h/sources/gdb-8.1/gdb/dwarf2read.c:10622 #16 0x0000000000620be8 in process_full_comp_unit (per_cu=0x49a58350, pretend_language=language_minimal) at /h/sources/gdb-8.1/gdb/dwarf2read.c:10396 #17 0x000000000061f9db in process_queue () at /h/sources/gdb-8.1/gdb/dwarf2read.c:9887 #18 0x0000000000610776 in dw2_do_instantiate_symtab (per_cu=0x49a58350) at /h/sources/gdb-8.1/gdb/dwarf2read.c:3104 #19 0x0000000000610818 in dw2_instantiate_symtab (per_cu=0x49a58350) at /h/sources/gdb-8.1/gdb/dwarf2read.c:3125 #20 0x0000000000614254 in dw2_lookup_symbol (objfile=0x334e6740, block_index=0, name=0x107bba00 "size_t", domain=VAR_DOMAIN) at /h/sources/gdb-8.1/gdb/dwarf2read.c:4304 #21 0x00000000007b54ae in lookup_symbol_via_quick_fns (objfile=0x334e6740, block_index=0, name=0x107bba00 "size_t", domain=VAR_DOMAIN) at /h/sources/gdb-8.1/gdb/symtab.c:2383 #22 0x00000000007b58ba in lookup_symbol_in_objfile (objfile=0x334e6740, block_index=0, name=0x107bba00 "size_t", domain=VAR_DOMAIN) at /h/sources/gdb-8.1/gdb/symtab.c:2558 #23 0x00000000007b5aff in lookup_symbol_global_iterator_cb (objfile=0x334e6740, cb_data=0x7ffe2ecfcce0) at /h/sources/gdb-8.1/gdb/symtab.c:2641 #24 0x0000000000717ab7 in default_iterate_over_objfiles_in_search_order (gdbarch=0x14a4f40, cb=0x7b5a7d , cb_data=0x7ffe2ecfcce0, current_objfile=0x0) at /h/sources/gdb-8.1/gdb/objfiles.c:1548 #25 0x000000000069be36 in gdbarch_iterate_over_objfiles_in_search_order (gdbarch=0x14a4f40, cb=0x7b5a7d , cb_data=0x7ffe2ecfcce0, current_objfile=0x0) at /h/sources/gdb-8.1/gdb/gdbarch.c:4825 #26 0x00000000007b5c44 in lookup_global_symbol (name=0x107bba00 "size_t", block=0x0, domain=VAR_DOMAIN) at /h/sources/gdb-8.1/gdb/symtab.c:2687 #27 0x00000000005d9ec1 in cp_lookup_bare_symbol (langdef=0xa1b780 , name=0x107bba00 "size_t", block=0x0, domain=VAR_DOMAIN, search=1) at /h/sources/gdb-8.1/gdb/cp-namespace.c:204 #28 0x00000000005dae00 in lookup_namespace_scope (langdef=0xa1b780 , name=0x107bba00 "size_t", block=0x0, domain=VAR_DOMAIN, scope=0xa0b5ea "", scope_len=0) at /h/sources/gdb-8.1/gdb/cp-namespace.c:721 #29 0x00000000005daf2f in cp_lookup_symbol_nonlocal (langdef=0xa1b780 , name=0x107bba00 "size_t", block=0x0, domain=VAR_DOMAIN) at /h/sources/gdb-8.1/gdb/cp-namespace.c:756 #30 0x00000000007b4c03 in lookup_symbol_aux (name=0x107bba00 "size_t", match_type=symbol_name_match_type::FULL, block=0x0, domain=VAR_DOMAIN, language=language_cplus, is_a_field_of_this=0x0) at /h/sources/gdb-8.1/gdb/symtab.c:2091 #31 0x00000000007b43f8 in lookup_symbol_in_language (name=0x107bba00 "size_t", block=0x0, domain=VAR_DOMAIN, lang=language_cplus, is_a_field_of_this=0x0) at /h/sources/gdb-8.1/gdb/symtab.c:1887 #32 0x00000000007b4472 in lookup_symbol (name=0x107bba00 "size_t", block=0x0, domain=VAR_DOMAIN, is_a_field_of_this=0x0) at /h/sources/gdb-8.1/gdb/symtab.c:1899 #33 0x00000000005dcce5 in replace_typedefs (info=0xa0e925c0, ret_comp=0xadd93430, finder=0x5b8ded , data=0x7ffe2ecfd280) at /h/sources/gdb-8.1/gdb/cp-support.c:431 #34 0x00000000005dcf80 in cp_canonicalize_string_full (string=0x15b2dd0 "size_t", finder=0x5b8ded , data=0x7ffe2ecfd280) at /h/sources/gdb-8.1/gdb/cp-support.c:521 #35 0x00000000005b8e5d in print_name_maybe_canonical (name=0x15b2dd0 "size_t", flags=0x7ffe2ecfd280, stream=0x1376300) at /h/sources/gdb-8.1/gdb/c-typeprint.c:90 #36 0x00000000005bd162 in c_type_print_base_1 (type=0x1794c30, stream=0x1376300, show=-1, level=0, flags=0x7ffe2ecfd280, podata=0x7ffe2ecfd250) at /h/sources/gdb-8.1/gdb/c-typeprint.c:1571 #37 0x00000000005b8fa7 in c_print_type_1 (type=0x1794c30, varstring=0xaa03d3 "", stream=0x1376300, show=-1, level=0, flags=0x7ffe2ecfd280, podata=0x7ffe2ecfd250) at /h/sources/gdb-8.1/gdb/c-typeprint.c:126 #38 0x00000000005b9151 in c_print_type (type=0x1794c30, varstring=0xaa03d3 "", stream=0x1376300, show=-1, level=0, flags=0x7ffe2ecfd280) at /h/sources/gdb-8.1/gdb/c-typeprint.c:172 #39 0x0000000000812919 in whatis_exp (exp=0x1207067 "slow", show=-1) at /h/sources/gdb-8.1/gdb/typeprint.c:541 #40 0x000000000081297a in whatis_command (exp=0x1207067 "slow", from_tty=1) at /h/sources/gdb-8.1/gdb/typeprint.c:553 #41 0x0000000000470136 in do_const_cfunc (c=0x13465a0, args=0x1207067 "slow", from_tty=1) at /h/sources/gdb-8.1/gdb/cli/cli-decode.c:106 # -- http://www.productive-cpp.com/