From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24478 invoked by alias); 3 Feb 2011 08:59:23 -0000 Received: (qmail 24470 invoked by uid 22791); 3 Feb 2011 08:59:22 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Thu, 03 Feb 2011 08:59:13 +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.13.8/8.13.8) with ESMTP id p138xBDj020182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 Feb 2011 03:59:11 -0500 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p138x937019394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 03:59:10 -0500 Received: from host1.dyn.jankratochvil.net (localhost [127.0.0.1]) by host1.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p138x86J009209; Thu, 3 Feb 2011 09:59:08 +0100 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id p138x87k009208; Thu, 3 Feb 2011 09:59:08 +0100 Date: Thu, 03 Feb 2011 08:59:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFC: handle case arising from GCC PR 47510 Message-ID: <20110203085907.GA16851@host1.dyn.jankratochvil.net> References: <20110202211220.GA9781@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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: 2011-02/txt/msg00042.txt.bz2 On Wed, 02 Feb 2011 23:03:55 +0100, Tom Tromey wrote: > Tom> +public: > Tom> + C() {} > Tom> + ~C() {} > > Jan> If the destructor is not present maybe_smash_one_typedef() will not > Jan> work. And GDB crashes now due to it, that should be > Jan> sanity-protected anyway. > > The class C is not the problem in this test case. I think C just exists > to make sure that the "anonymous" struct is not a POD. > > maybe_smash_one_typedef won't be called for C, because C has a name. > > I don't understand about GDB crashing now due to C. C itself isn't a problem. But as C no longer has a destructor even `t' no longer has an implicit destructor. Due to it maybe_smash_one_typedef gets called for `t' but it does not do anything as it does not find the '~' field. Then cp_lookup_nested_type crashes as TYPE_TAG_NAME (parent_type) == NULL - which is correct for anonymous struct - but cp_lookup_nested_type does not expect it. > Jan> I do not fully grok this change, it goes half way. Why two > Jan> artificial methods are not non-unique? > > My understanding is that this loop is trying to filter out artificial > methods in a case like: > > class K { > K(int) { ... } > }; > > Here, I think, the user can type "ptype K::K" and get "K::K(int)" -- > which makes some kind of sense, ignoring the compiler-generated > K::K(void). At least, that is what I think it all means. I am not sure > this code is really correct, but this part of the patch is just avoiding > a crash. > > I don't think it is possible for this loop to see two artificial > methods. I thought about: class C { public: C() {} }; class CC { C cf; } cc; class D : CC {} d; int main () {} built with: GNU C++ 4.4.6 20110124 (prerelease) producing: nm -C file 00000000004005ac W CC::CC() 0000000000400592 W CC::CC() GDB HEAD: (gdb) p CC::CC Cannot reference virtual member function "CC" GDB with your patch: (gdb) p CC::CC $1 = {void (CC * const)} 0x400592 (that is the 0x4005ac function is not shown to the user) But this problem is not related to this patch as it happens even with non-artificial constructors. lookup_symbol_aux_symtabs just returns the first matching symbol. But one cannot specify demangled name for specific kind of ctor/dtor so lookup_symbol_aux_symtabs must not error on non-unique match. g++-4.5+ no longer generates multiple kinds of constructors during my tests so it should not be much a real world concern anymore. value_struct_elt_for_reference in this case sees only a single CC::CC entry as the abstract structure itself has only one DIE for CC::CC. So not an applicable issue for this patch. Thanks, Jan