From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20451 invoked by alias); 31 Oct 2012 19:18:00 -0000 Received: (qmail 20443 invoked by uid 22791); 31 Oct 2012 19:18:00 -0000 X-SWARE-Spam-Status: No, hits=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Oct 2012 19:17:49 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9VJHmTi017273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 31 Oct 2012 15:17:49 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q9VJHlFQ012590; Wed, 31 Oct 2012 15:17:48 -0400 Message-ID: <5091795B.7020506@redhat.com> Date: Wed, 31 Oct 2012 19:18:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: Tom Tromey CC: gdb-patches@sourceware.org Subject: Re: [PATCH 8/9] class-local typedef substitutions References: <87vcfphdl8.fsf@fleche.redhat.com> <87sjabrx4g.fsf@fleche.redhat.com> In-Reply-To: <87sjabrx4g.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-10/txt/msg00568.txt.bz2 On 09/21/2012 08:31 PM, Tom Tromey wrote: > Tom> This patch implements class-local typedef substitutions for the C++ > Tom> type printer. That is, when printing a type, gdb will now look at > Tom> template argument names (if any) and typedefs defined in the class > Tom> body, and substitute those names when printing type names. > > More testing revealed an oddity in this code (a latent bug exposed by > the subsequent Python patch); and the fix I chose required some changes > to some MI test cases as well. The particular change was that > previously gdb could emit "long int" but now it will emit just "long" -- > I consider this to be an ok (perhaps even preferable) change. I'm confused and curious at why such a change would be necessary. I couldn't find it from a quick look over the patch. Can you expand a little? Does this also affect the CLI? Why expect both long and "long int"? Is this compiler / debug format dependent, perhaps? > mi_list_varobj_children {struct_declarations.long_array --all-values} { > - {struct_declarations.long_array.0 0 0 "long int" 1234} > - {struct_declarations.long_array.1 1 0 "long int" 2345} > - {struct_declarations.long_array.2 2 0 "long int" 3456} > - {struct_declarations.long_array.3 3 0 "long int" 4567} > - {struct_declarations.long_array.4 4 0 "long int" 5678} > - {struct_declarations.long_array.5 5 0 "long int" 6789} > - {struct_declarations.long_array.6 6 0 "long int" 7890} > - {struct_declarations.long_array.7 7 0 "long int" 8901} > - {struct_declarations.long_array.8 8 0 "long int" 9012} > - {struct_declarations.long_array.9 9 0 "long int" 1234} > - {struct_declarations.long_array.10 10 0 "long int" 3456} > - {struct_declarations.long_array.11 11 0 "long int" 5678} > + {struct_declarations.long_array.0 0 0 "long( int)?" 1234} > + {struct_declarations.long_array.1 1 0 "long( int)?" 2345} > + {struct_declarations.long_array.2 2 0 "long( int)?" 3456} > + {struct_declarations.long_array.3 3 0 "long( int)?" 4567} > + {struct_declarations.long_array.4 4 0 "long( int)?" 5678} > + {struct_declarations.long_array.5 5 0 "long( int)?" 6789} > + {struct_declarations.long_array.6 6 0 "long( int)?" 7890} > + {struct_declarations.long_array.7 7 0 "long( int)?" 8901} > + {struct_declarations.long_array.8 8 0 "long( int)?" 9012} > + {struct_declarations.long_array.9 9 0 "long( int)?" 1234} > + {struct_declarations.long_array.10 10 0 "long( int)?" 3456} > + {struct_declarations.long_array.11 11 0 "long( int)?" 5678} > } "listing of names and values of children" > mi_list_varobj_children "psnp->long_ptr" { > - {{psnp->long_ptr.\*psnp->long_ptr} {\*psnp->long_ptr} 1 {long int \*\*\*}} > + {{psnp->long_ptr.\*psnp->long_ptr} {\*psnp->long_ptr} 1 {long( int)? \*\*\*}} > } "get children of psnp->long_ptr" > -- Pedro Alves