From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29136 invoked by alias); 23 Nov 2009 17:08:23 -0000 Received: (qmail 29128 invoked by uid 22791); 23 Nov 2009 17:08:23 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Nov 2009 17:07:18 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0A29A10DAA; Mon, 23 Nov 2009 17:07:16 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 7453F10D9E; Mon, 23 Nov 2009 17:07:15 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1NCcNa-00049y-J9; Mon, 23 Nov 2009 12:07:10 -0500 Date: Mon, 23 Nov 2009 17:08:00 -0000 From: Daniel Jacobowitz To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname Message-ID: <20091123170710.GA15216@caradoc.them.org> Mail-Followup-To: Keith Seitz , gdb-patches@sourceware.org References: <4B0707E7.5010308@uglyboxes.com> <20091120220927.GA9589@caradoc.them.org> <4B0ABD84.5040606@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0ABD84.5040606@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00494.txt.bz2 On Mon, Nov 23, 2009 at 08:51:16AM -0800, Keith Seitz wrote: > 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.] If it applies on top of this, could he post it now? Then we can treat them as a unit for review and testing purposes. > >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. Might need to be arm-eabi for some cases, I'm not sure. I haven't tried arm-elf in a while. > >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.] Right. I figured this out after the fact. Did I send you my local implementation of DW_TAG_template_value_parameter? It's... not pretty. > >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. Will do. Rerunning with cpexprs.exp included this time. > If we can define a suitable test procedure for this, I would be happy > to produce some comparisons. I'd like to leave Tom's work - exciting as it is - out of the discussion for the moment. I suggest picking a couple of C++ programs, preferably with different degrees of template-ness. The interesting numbers are, IMO: * psymtab creation ("time gdb -batch foo"). * full symbol creation ("time gdb -batch -readnow foo"). * some vaguely realistic operation, e.g. set a breakpoint near the start of the application and run it through loading shared libraries and print a backtrace. -readnow numbers are interesting, but not vital. That is, a big slowdown there is not necessarily a big problem. Thoughts? -- Daniel Jacobowitz CodeSourcery