From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18453 invoked by alias); 8 Dec 2009 19:47:53 -0000 Received: (qmail 18443 invoked by uid 22791); 8 Dec 2009 19:47:53 -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; Tue, 08 Dec 2009 19:47:48 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nB8Jllr0015795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Dec 2009 14:47:47 -0500 Received: from [IPv6:::1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nB8JleDq022728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Dec 2009 14:47:45 -0500 Message-ID: <4B1EAD5C.6060708@redhat.com> Date: Tue, 08 Dec 2009 19:47: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-12/txt/msg00121.txt.bz2 I apologize for the delay... It's been a week of holidays and debugging... On 11/20/2009 02:09 PM, Daniel Jacobowitz wrote: > The related regressions, just with arm-none-eabi GCC and the default > multilib: > > 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) I've tracked this down to a misfeature I introduced to strcmp_iw to deal with "const" and "volatile". I've removed that, since I don't think that is the proper way to do this anymore. These tests now all pass. [I am also testing arm-eabi with the default multilib on the simulator.] > 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 These are failing because the fully qualified name of "__cxxabiv1::__cxa_throw" is being shown in the backtraces instead of just "__cxa_throw". > PASS -> FAIL: default/gdb.sum:gdb.cp/namespace.exp: print X > PASS -> FAIL: default/gdb.sum:gdb.cp/namespace.exp: print cX I think we've already established that these are fixed by Sami's outstanding patch (under review). >> 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. Yeah, this is *really* bad. Really, really bad. But this was just a an attempt at "making it work." Now comes the "make it faster" part. I have a few ideas about redundant calls and whatnot, but it will undoubtedly take some real effort and refactoring to really make the best of this. I'm working on some performance numbers now with OpenOffice.org Writer as Tom suggested. I'll follow up on this later in this thread when I have some more data collected. Keith