From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13098 invoked by alias); 17 May 2011 18:15:39 -0000 Received: (qmail 13088 invoked by uid 22791); 17 May 2011 18:15:38 -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; Tue, 17 May 2011 18:15:21 +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 p4HIFKQ3020328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 May 2011 14:15:20 -0400 Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p4HIFIkS024631 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 17 May 2011 14:15:19 -0400 Message-ID: <4DD2BB36.5000704@redhat.com> Date: Tue, 17 May 2011 18:15: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: [rfc] physname cross-check [Re: [RFA] Typedef'd method parameters [0/4]] References: <4DB09E6C.8000202@redhat.com> <4DCC50D8.5030903@redhat.com> <20110516154851.GA24555@host1.jankratochvil.net> In-Reply-To: <20110516154851.GA24555@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/msg00385.txt.bz2 On 05/16/2011 08:48 AM, Jan Kratochvil wrote: > I wrote a cross-check of what GDB thinks is the physname (which is in > demangled canonical form) vs. what GCC thinkgs is the physname (which needs to > be converted from mangled form and canonicalized). That's a great idea! "Why didn't I think of that?" (famous last words) > It reports for me 34524 unique failures on libwebkit.so.debug. (Sure such > count is caused only by a few physname computation bugs.) I will start looking into these and filing/fixing bugs when my plate opens up here in the next day or two. > Therefore I would propose a sinful idea to temporarily just use > DW_AT_linkage_name if it is available to ever release gdb-7.3 and make > DW_AT_linkage_name-less GDB a feature for gdb-7.4. After all such cross-check > should exist anyway for verifying both GCC and GDB bugs this way. For me, what really matters is what is best for users. Is reverting dwarf2_physname better or worse than DW_AT_MIPS_linkage_name? That's a difficult question to answer in a black-and-white way, really, but my instincts (which could be wrong, of course) tell me that MIPS_linkage_name is the greater of two evils. > cat>1.h< struct x {}; > class C { public: void m (x *xp); }; > EOH > cat>1.C< #include "1.h" > C c; > int main () { c.m(0); } > EOH > cat>1b.C< #include "1.h" > void C::m (x *xp) {} > EOH I've fixed this bug. This was just introduced in this patchset because the typeprinter did not recognize that in C++, "struct" = "class". [To be clear, it was *my* patch which introduced this inequality.] I have fixed this my patchset, and I have added a test for it. Unfortunately, I must reiterate that I am a slave to the test suite. While I try my best to test everything that comes to mind, ultimately, not everything comes to (my) mind. > Just it has some other existing testsuite regressions: > gdb.cp/bs15503.exp gdb.cp/cp-relocate.exp gdb.cp/cpexprs.exp > gdb.java/jmisc.exp gdb.java/jprint.exp Using DW_AT_MIPS_linkage_name will not pass cpexprs.exp without some hacking; the demangled name will need to be re-parsed (to remove typedefs -- that might be a bit easier with this patchset) and subsequently canonicalize the result. I really see this as an even bigger risk than keeping the current code. And then there's constructors -- no version of GCC that I've seen outputs DW_AT_MIPS_linkage_name for ctors, so they would still have to be computed in some way. > What do you think? In the end, it probably doesn't really matter what I think. :-) IMO, this all boils down to risk management. Which path is least risky for users and most conducive to moving forward? This is a decision for you and other maintainers to consider. Keith