From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77977 invoked by alias); 17 Jul 2018 14:38:44 -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 77952 invoked by uid 89); 17 Jul 2018 14:38:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.2 spammy=whatis, onlinedocs X-HELO: sesbmg22.ericsson.net Received: from sesbmg22.ericsson.net (HELO sesbmg22.ericsson.net) (193.180.251.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jul 2018 14:38:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1531838318; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aVEkSdvbE6f+inCrTcA+sYdvVuj1rEbUZwCpapeJfL4=; b=ZqseS7jWFfdxr2nIpiTw8C/Fr8a9ZxnnAX2NiMj8lcy9uQrK6WHNFHqx16F41aKp 1r3fNUonc2l16Ji6p0X47ZVZv7aiT+8GLMPd6M3Q6JFyqOIcZjiw8vJm2mBkptYr SmF+vQf6zNqTodoIHQpHy4m+/na5pMG0hcrGa7/ADmU=; Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.D8.22978.E6FFD4B5; Tue, 17 Jul 2018 16:38:38 +0200 (CEST) Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESBMB505.ericsson.se (153.88.183.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 17 Jul 2018 16:38:38 +0200 Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 17 Jul 2018 16:38:37 +0200 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 17 Jul 2018 16:38:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tzWoLseVaCp/I34RxKukMfwDhE/0lltf2PKcjr+YLEg=; b=GHimmY+zSXZGT2J4ubbt/N5xydvxNLRs/I1MJ8ckGVzOrj2Adk+94fsCwo69c5KZbtv/8anBC75/xtm+TWwDdOoa4VDxpUpTsD/LR4mH7xL8hvr6pIZ96Z7DehIBN3ZBcg4Vs6j6mmy++3QWpgDry+MEC/5iexS98I1NEhuqT9I= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [142.133.61.147] (192.75.88.130) by SN6PR15MB2398.namprd15.prod.outlook.com (2603:10b6:805:24::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.19; Tue, 17 Jul 2018 14:38:34 +0000 Subject: Re: MI: -var-create does not resolve typedefs To: Martin Richtarsky , References: <8d8b95e9218d09f8d808936b4a9f163e-EhVcX1dJRwNeRwQRAQsKVxcwfgFLV15YQUBGAEFbWkA3VF0NQVpwH1FRQ15bQyoDWllYRVlWWQ1e-webmailer1@server03.webmailer.hosteurope.de> From: Simon Marchi Message-ID: <920a0f43-7ccf-5805-61d7-7fb645d4fbb3@ericsson.com> Date: Tue, 17 Jul 2018 14:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8d8b95e9218d09f8d808936b4a9f163e-EhVcX1dJRwNeRwQRAQsKVxcwfgFLV15YQUBGAEFbWkA3VF0NQVpwH1FRQ15bQyoDWllYRVlWWQ1e-webmailer1@server03.webmailer.hosteurope.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-Path: simon.marchi@ericsson.com Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00034.txt.bz2 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::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