From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24609 invoked by alias); 24 Mar 2010 20:24:06 -0000 Received: (qmail 24599 invoked by uid 22791); 24 Mar 2010 20:24:05 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_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; Wed, 24 Mar 2010 20:24:01 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2OKNwJ0007812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Mar 2010 16:23:58 -0400 Received: from [IPv6:::1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2OKNsTi016518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Mar 2010 16:23:57 -0400 Message-ID: <4BAA74DA.6060606@redhat.com> Date: Wed, 24 Mar 2010 20:24:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc11 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: Ulrich Weigand CC: gdb-patches@sourceware.org Subject: Re: [RFA] dwarf2_physname FINAL References: <201003232024.o2NKOqIZ019784@d12av02.megacenter.de.ibm.com> In-Reply-To: <201003232024.o2NKOqIZ019784@d12av02.megacenter.de.ibm.com> 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: 2010-03/txt/msg00818.txt.bz2 On 03/23/2010 01:24 PM, Ulrich Weigand wrote: > Would it be possible to KFAIL that? I should think so... :-) If maintainers wish it so, it will be done. > <2><223>: Abbrev Number: 6 (DW_TAG_subprogram) > DW_AT_external : 1 > DW_AT_name : > DW_AT_MIPS_linkage_name: _ZN5jmiscC1Ev > DW_AT_artificial : 1 > DW_AT_declaration : 1 > > Is this to be expected? Or should this be handled by the new code > somewhere? No, it's not. I have a patch for this, but I've noticed some other little java regressions (which are not tested by the test suite), so I am going to delay submitting my patch until I can get the problems all worked out. > Also, I'm now seeing three failures in the new cpexprs.exp: > FAIL: gdb.cp/cpexprs.exp: list base::overload(void) > FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::overload(void) > FAIL: gdb.cp/cpexprs.exp: continue to base::overload(void) > apparently related to whether "const" needs to be specified when > identifying an overloaded method. I seem to recall some reference > to this problem in one of the dwarf2_physname threads -- is this > still an expected problem with the final patch? Yeah, I meant to return to this, but got caught up in one thing or another. I will attempt to fix this (or XFAIL it) when I get the above Java issues sorted out. Keith