From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32656 invoked by alias); 23 Nov 2009 16:52:33 -0000 Received: (qmail 32628 invoked by uid 22791); 23 Nov 2009 16:52:31 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS 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; Mon, 23 Nov 2009 16:51:23 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nANGpMJP004283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Nov 2009 11:51:22 -0500 Received: from [IPv6:::1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nANGpGL5013193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Nov 2009 11:51:20 -0500 Message-ID: <4B0ABD84.5040606@redhat.com> Date: Mon, 23 Nov 2009 16:52:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname References: <4B0707E7.5010308@uglyboxes.com> <20091120220927.GA9589@caradoc.them.org> In-Reply-To: <20091120220927.GA9589@caradoc.them.org> 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: 2009-11/txt/msg00492.txt.bz2 On 11/20/2009 02:09 PM, Daniel Jacobowitz wrote: > I am generally opposed to committing known regressions. If there are > supporting patches we need to get in first, let's do that; if there > are tests we decide to break, let's XFAIL or KFAIL them. That's the > only way we can make the testsuite more useful. Sami has a follow-on patch that he could submit to fix all of these tests (they all pass on archer-keiths-expr-cumulative). Perhaps it would be acceptable for Sami to submit that patchset when/if this patch is accepted? [His patches rely on this patchset.] > The related regressions, just with arm-none-eabi GCC and the default > multilib: I'm building an arm-elf toolchain now, and I will run it through testing. > PASS -> FAIL: default/gdb.sum:gdb.base/code-expr.exp: (@code signed long) > PASS -> FAIL: default/gdb.sum:gdb.base/code-expr.exp: (@data signed long) > PASS -> FAIL: default/gdb.sum:gdb.base/code-expr.exp: (signed long @code) > PASS -> FAIL: default/gdb.sum:gdb.base/code-expr.exp: (signed long @data) > PASS -> FAIL: default/gdb.sum:gdb.base/cvexpr.exp: (const signed long) > PASS -> FAIL: default/gdb.sum:gdb.base/cvexpr.exp: (signed long const) > PASS -> FAIL: default/gdb.sum:gdb.base/cvexpr.exp: (signed long volatile) > PASS -> FAIL: default/gdb.sum:gdb.base/cvexpr.exp: (volatile signed long) > PASS -> FAIL: default/gdb.sum:gdb.cp/exception.exp: backtrace after first catch > PASS -> FAIL: default/gdb.sum:gdb.cp/exception.exp: backtrace after first throw > PASS -> FAIL: default/gdb.sum:gdb.cp/exception.exp: backtrace after second catch > PASS -> FAIL: default/gdb.sum:gdb.cp/exception.exp: backtrace after second throw Don't know about the above failures just yet, but... > PASS -> FAIL: default/gdb.sum:gdb.cp/namespace.exp: print X > PASS -> FAIL: default/gdb.sum:gdb.cp/namespace.exp: print cX These are the two regressions that are addressed by Sami's (unsubmitted) patch. > I'm going to skip the RealView regressions; those I'm willing to > handle in followups. Most template tests still fail with RealView. > Some tests from namespace.exp improved, others regressed. I think we discussed it earlier, but to be clear: RealView will demonstrate problems with templates, since it relies on DW_TAG_template_{value,type}_parameter, which gdb does not yet understand. [I've played with it a bit, but value parameters are *tough* on dwarf2_physname.] > Any idea what the above failures might be? I can send you logs > offlist, they're large. Yes, send the to me at this account. >> Some warnings are in order. First, this is probably going to really >> slow down large C++ applications, because we no longer use >> DW_AT_MIPS_linkage_name as generated from the compiler. We >> essentially build this name during DIE reading. > > We need to quantify the impact on a couple of C++ code bases, I think. Indeed. I ran some contrived speed tests a long time ago, but I never really felt that the adequately represented reality. [I believe they were the equivalent of running "file XXX; info func".] We did show a slowdown on OO.o, but I don't recall the exact numbers right now. If we can define a suitable test procedure for this, I would be happy to produce some comparisons. Keith