From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35308 invoked by alias); 8 Sep 2018 11:01:10 -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 35297 invoked by uid 89); 8 Sep 2018 11:01:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Sep 2018 11:01:07 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w88B111g028586 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 8 Sep 2018 07:01:06 -0400 Received: by simark.ca (Postfix, from userid 112) id F15391E75F; Sat, 8 Sep 2018 07:01:00 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id B4FA51E16B; Sat, 8 Sep 2018 07:00:59 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 08 Sep 2018 11:01:00 -0000 From: Simon Marchi To: Martin Richtarsky Cc: gdb@sourceware.org, simon.marchi@ericsson.com Subject: Re: MI: -var-create does not resolve typedefs In-Reply-To: <244d2f88027af80aae3812b0597e8c19-EhVcX1dJRwNeRwQRAQsKVxcwfgFLV15YQUBGAEFbWkA3VF0NQVpwH1FRQ15cRioDWllfQ1tUUAlZ-webmailer1@server06.webmailer.hosteurope.de> References: <8d8b95e9218d09f8d808936b4a9f163e-EhVcX1dJRwNeRwQRAQsKVxcwfgFLV15YQUBGAEFbWkA3VF0NQVpwH1FRQ15bQyoDWllYRVlWWQ1e-webmailer1@server03.webmailer.hosteurope.de> <920a0f43-7ccf-5805-61d7-7fb645d4fbb3@ericsson.com> <244d2f88027af80aae3812b0597e8c19-EhVcX1dJRwNeRwQRAQsKVxcwfgFLV15YQUBGAEFbWkA3VF0NQVpwH1FRQ15cRioDWllfQ1tUUAlZ-webmailer1@server06.webmailer.hosteurope.de> Message-ID: <19e18d505835f8704a18af5f56f2aa15@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00016.txt.bz2 On 2018-09-07 15:50, Martin Richtarsky wrote: > 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::char_traits, >>> 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? By any chance, is the application you debug free/open, so I could build it? It's quite difficult to reproduce performance problems synthetically, so if I was able to debug the same thing as you, we could compare apples to apples. Otherwise, if you are able to reproduce it with another large free software project, it could work too. Thanks, Simon