From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16487 invoked by alias); 20 Nov 2009 22:10:36 -0000 Received: (qmail 16479 invoked by uid 22791); 20 Nov 2009 22:10:35 -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; Fri, 20 Nov 2009 22:09:30 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id A464610B94; Fri, 20 Nov 2009 22:09:28 +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 7BF0D10B25; Fri, 20 Nov 2009 22:09:28 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1NBbfT-0002lA-5G; Fri, 20 Nov 2009 17:09:27 -0500 Date: Fri, 20 Nov 2009 22:10:00 -0000 From: Daniel Jacobowitz To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname Message-ID: <20091120220927.GA9589@caradoc.them.org> Mail-Followup-To: Keith Seitz , gdb-patches@sourceware.org References: <4B0707E7.5010308@uglyboxes.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0707E7.5010308@uglyboxes.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/msg00451.txt.bz2 On Fri, Nov 20, 2009 at 01:19:35PM -0800, Keith Seitz wrote: > The attached patch is the real "meat and potatoes" of the thing. It > includes much of the earlier patches that I posted on August 31, > except that this leaves out none of the details. Actually reviewing this is going to take more time than I have today, but the first thing I wanted to do was drop it into my RealView test harness and see what happened. Across three RealView multilibs and two ARM GCC multilibs: 495 FAIL -> PASS 75 New FAIL 130 PASS -> FAIL 87 Removed FAIL 3 Removed KPASS 6 UNRESOLVED -> PASS Pretty good. A few of the failures were related to another patch I had on my last test run which is still pending. Some of the PASS -> FAIL are with GCC though. 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. 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) 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 PASS -> FAIL: default/gdb.sum:gdb.cp/namespace.exp: print X PASS -> FAIL: default/gdb.sum:gdb.cp/namespace.exp: print cX 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. Any idea what the above failures might be? I can send you logs offlist, they're large. > 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. -- Daniel Jacobowitz CodeSourcery