From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13995 invoked by alias); 20 May 2011 20:39:08 -0000 Received: (qmail 13987 invoked by uid 22791); 20 May 2011 20:39:07 -0000 X-SWARE-Spam-Status: No, hits=-6.9 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; Fri, 20 May 2011 20:38:54 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4KKcrX9007006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 May 2011 16:38:53 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p4KKcr7w000988; Fri, 20 May 2011 16:38:53 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p4KKcq5g016491; Fri, 20 May 2011 16:38:52 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 4F31A378D08; Fri, 20 May 2011 14:38:52 -0600 (MDT) From: Tom Tromey To: Keith Seitz Cc: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: The future of dwarf2_physname References: <4DD44983.7060406@redhat.com> <20110519192316.GA7075@host1.jankratochvil.net> <4DD6C6B4.7060406@redhat.com> Date: Fri, 20 May 2011 20:39:00 -0000 In-Reply-To: <4DD6C6B4.7060406@redhat.com> (Keith Seitz's message of "Fri, 20 May 2011 12:53:24 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00501.txt.bz2 Keith> I wouldn't say that DW_AT_MIPS_linkage_name is any more ISO C++ Keith> compliant than anything else. Just because the compiler outputs it Keith> does not necessarily make it sacrosanct. [gcc/33861] I think that bug shows the opposite, actually. If you look at the DWARF: <1><25>: Abbrev Number: 2 (DW_TAG_structure_type) <26> DW_AT_name : (indirect string, offset: 0x77): Qux<((char*)(& name))> That is, the bug here is that G++ emits a bad and weird DW_AT_name. But, if you look at the member function: <2><31>: Abbrev Number: 3 (DW_TAG_subprogram) <32> DW_AT_external : 1 <33> DW_AT_name : foo <37> DW_AT_decl_file : 1 <38> DW_AT_decl_line : 7 <39> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x5a): _ZN3QuxIXadL_Z4nameEEE3fooEv .. run through c++filt: <39> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x5a): Qux<&name>::foo() Here, the linkage name and demangler are correct. Also even if you strip down the class' DW_AT_name, you probably have trouble reconstructing the template argument: <2><51>: Abbrev Number: 5 (DW_TAG_template_value_param) <52> DW_AT_name : V <54> DW_AT_type : <0xaf> <58> DW_AT_location : 6 byte block: 3 0 0 0 0 9f (DW_OP_addr: 0; DW_OP_stack_value) ... since that is just the address of 'name', which IIUC may appear elsewhere, perhaps without debuginfo. I guess it ought to always appear in minimal symbols in that case... maybe it isn't as bad as I thought. I get this from my patch branch: opsy. ../gdb -readnow -batch -ex 'set complaint 10000' -ex 'file /tmp/q.o' During symbol reading...Computed physname ::foo()> does not match demangled ::foo()> (from linkage <_ZN3QuxIXadL_Z4nameEEE3fooEv>) - DIE at 0x31 [in module /tmp/q.o]... Jan> That is the GCC and ISO C++ naming should be always available in Jan> GDB. I am not against allowing also other aliases for the same Jan> symbol. The availability of symbol aliases is discussed more at Jan> the end of this mail. Keith> I agree. Great, we have a starting point :) Jan> I do not see any real regressions except incorrect testcase assumptions. Keith> Unless the assumption is that gdb can only set breakpoints on linkage Keith> names, I don't call the test cases broken or illegal. If your argument Keith> is that you don't like the way it was solved, that's an entirely Keith> different assertion, and one with much more merit. Yes, I actually agree with both of you, in the sense that I think both sets of tests ought to pass. Tom