From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4950 invoked by alias); 20 May 2011 19:53:42 -0000 Received: (qmail 4937 invoked by uid 22791); 20 May 2011 19:53:41 -0000 X-SWARE-Spam-Status: No, hits=-5.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 19:53:26 +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 p4KJrQum026168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 20 May 2011 15:53:26 -0400 Received: from valrhona.uglyboxes.com (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 p4KJrOdS009940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 May 2011 15:53:25 -0400 Message-ID: <4DD6C6B4.7060406@redhat.com> Date: Fri, 20 May 2011 19:53:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.38.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org Subject: Re: The future of dwarf2_physname References: <4DD44983.7060406@redhat.com> <20110519192316.GA7075@host1.jankratochvil.net> In-Reply-To: <20110519192316.GA7075@host1.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-05/txt/msg00499.txt.bz2 Hi, Jan, On 05/19/2011 12:23 PM, Jan Kratochvil wrote: > If the linkage name is wrong for whatever reason this is an ABI issue for GCC, > it is out of scope of GDB. Linkage name is defined by the ISO C++ standard, > neither GCC nor GDB can change it. If GCC is not ISO C++ compliant then GCC > should be fixed (and possibly deal with the ABI breakage) but such ISO C++ > compliance issue is out of scope of GDB. We work around GCC ABI issues all the time GDB. dwarf2read.cc is riddled with workarounds for various flavors of GCC. > Trying to introduce new "better" naming for C++ methods which is in 90% the > same as GCC's and ISO C++'s idea seems a bit messy for me. If you mean "better" as in "more reliable", then I'm afraid that *was* the point. I don't like it, either, TBH, because there's a bunch of overhead involved. But it seemed like a reasonable thing to do at the time, and it still does, especially if you take GCC out of the discussion. I wouldn't say that DW_AT_MIPS_linkage_name is any more ISO C++ compliant than anything else. Just because the compiler outputs it does not necessarily make it sacrosanct. [gcc/33861] > That is the GCC and ISO C++ naming should be always available in GDB. I am > not against allowing also other aliases for the same symbol. The availability > of symbol aliases is discussed more at the end of this mail. I agree. > This is a regression. And it will always be a regression for any > physname != DW_AT_linkage_name as with my cross-check patch it prints: > Computed physname does not match demangled (from linkage<_ZNSt8ios_base6unsetfESt13_Ios_Fmtflags>) That's simply a bug. They get found, they get fixed. The sky is not falling. > I do not see any real regressions except incorrect testcase assumptions. Unless the assumption is that gdb can only set breakpoints on linkage names, I don't call the test cases broken or illegal. If your argument is that you don't like the way it was solved, that's an entirely different assertion, and one with much more merit. > $ nm -C gdb.cp/cp-relocate.o > 0000000000000000 W int func<1>(int) > print func<1>(int) > No symbol "func<1>" in current context. > (gdb) FAIL: gdb.cp/cp-relocate.exp: get address of func<1>(int) > > but: > (gdb) print 'int func<1>(int)' > $1 = {int (int)} 0x28(int)> > > This is a regression against gdb-7.2 (physname) but in pre-physname it also > did not work. The symbols canonicalization in decode_variable could also > strip the leading return types. Another bug slipped in. It, too, can be fixed. [That looks like a psymtab-related bug, btw.] But as I keep saying, I am not a maintainer. This is a decision for maintainers. I was simply asking how maintainers wanted me to proceed. Two maintainers believe that making the switch now is the best approach. As far as I am concerned, the matter is closed. Keith