From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6978 invoked by alias); 5 May 2011 17:10:36 -0000 Received: (qmail 6962 invoked by uid 22791); 5 May 2011 17:10:32 -0000 X-SWARE-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BAYES_00,KAM_STOCKTIP,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_FILL_THIS_FORM_SHORT,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate3.uk.ibm.com (HELO mtagate3.uk.ibm.com) (194.196.100.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 May 2011 17:10:13 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p45HA6ZM028756 for ; Thu, 5 May 2011 17:10:06 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p45HBIiQ2420838 for ; Thu, 5 May 2011 18:11:18 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p45HA56l016901 for ; Thu, 5 May 2011 11:10:06 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p45HA4Ym016889; Thu, 5 May 2011 11:10:04 -0600 Message-Id: <201105051710.p45HA4Ym016889@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 05 May 2011 19:10:04 +0200 Subject: Re: Is physname mangled or not? (PR c++/8216) To: drow@false.org (Daniel Jacobowitz) Date: Thu, 05 May 2011 17:10:00 -0000 From: "Ulrich Weigand" Cc: jan.kratochvil@redhat.com (Jan Kratochvil), gdb-patches@sourceware.org, keiths@redhat.com (Keith Seitz) In-Reply-To: <20110504175821.GA3141@caradoc.them.org> from "Daniel Jacobowitz" at May 04, 2011 01:58:21 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2011-05/txt/msg00145.txt.bz2 Daniel Jacobowitz wrote: > On Wed, May 04, 2011 at 07:32:43PM +0200, Ulrich Weigand wrote: > > It seems that by now we have agreement that GCC is correct here. So I guess > > I see two options remaining: > > > > - Code a test that compares class name and (demangled) function name, but > > explicitly removes template instance parameters first > > > > or > > > > - Have the symbol reader call is_constructor_name on the mangled name while > > it is still available, and store that information somewhere in the type > > information > > > > Thoughts? > > I'd suggest the former. Anything you do with mangled names will be > unexpectedly complex; sometimes you just can't count on having them. OK, I see. I've done a little more digging through the history, and I guess I understand a little better why things were done the way they were. Mostly, it seems to have come down to the problem that some past compilers used to fill in silly things for the debug data method names of special methods like constructors (e.g. __comp_ctor). See the long comment in stabsread.c:read_member_functions. To work around this, the code tries to "re-create" the proper method name using a variety of approaches, amongst others by looking at the physname (which at this point is a mangled name) if present (in stabs). Mostly, this gets done when the method definition is read in. However, there are cases where this is apparently not possible, and the method is marked as a "stub". There is a routine check_stub_method_group that users of the method list are apparently supposed to call before looking at method names, which "unstubs" methods and corrects all names as appropriate. This is done in various places (search_struct_method etc.). However, there are other places -in particular c_type_print_base, which is what initially started this discussion- that do *not* call the helper check_stub_method_group to fix things up. Instead (apparently) those places try to handle stubbed methods directly, duplicating various parts of what check_stub_method_group would do (e.g. call gdb_mangle_name). *This* in turn appears to be the reason why c_type_print_base does the weird duplicate check for constructors/destructors looking both at the method name and the physname -- the former is needed because physname is not always available, the latter is needed because the method name may be wrong for stubbed methods. So, if the analysis so far is correct, it would appear to me that the best way forward is actually to: - change c_type_print_base (and other places) to actually just call check_stub_method_group, and then assume the method name is always correct -- removing all the extra code required for stubbed methods, including the physname-based constructor/destructor checks - update the method name based checks to handle templates. B.t.w. at yet another location in linespec.c:find_methods, an attempt to handle templates seems to have been made when detecting constructors: else if (strncmp (class_name, name, name_len) == 0 && (class_name[name_len] == '\0' || class_name[name_len] == '<')) Does this look reasonable? Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com