From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7304 invoked by alias); 23 Jun 2015 18:39:57 -0000 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 Received: (qmail 7241 invoked by uid 89); 23 Jun 2015 18:39:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,KAM_STOCKGEN,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 23 Jun 2015 18:39:55 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 6A7BFB6F59; Tue, 23 Jun 2015 18:39:54 +0000 (UTC) Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5NIdqm3019534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jun 2015 14:39:54 -0400 Message-ID: <5589A7F8.7080406@redhat.com> Date: Tue, 23 Jun 2015 18:39:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org CC: Jan Kratochvil , dje@google.com Subject: Re: [RFC] Revisit PR 16253 ("Attempt to use a type name...") References: <1434049038-7891-1-git-send-email-keiths@redhat.com> <20150617123357.GA12138@host1.jankratochvil.net> <5581972B.3020200@redhat.com> In-Reply-To: <5581972B.3020200@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00497.txt.bz2 On 06/17/2015 08:50 AM, Keith Seitz wrote: > On 06/17/2015 05:33 AM, Jan Kratochvil wrote: >> On Thu, 11 Jun 2015 20:57:18 +0200, Keith Seitz wrote: >>> PR 16253 >>> * block.c (block_lookup_symbol_primary): If a symbol is found >>> which does not exactly match the requested domain, keep searching >>> for an exact match. Otherwise, return the previously found "best" >>> symbol. >> >> Is there a reason why you haven't patched also block_lookup_symbol? > > Two reasons: > > 1) I posted this RFC to raise discussion whether this was worth > pursuing. No need to expend any energy on something that has zero chance > of being accepted by maintainers. > > 2) More important I have not discovered/attempted to coverage test > lookup_block_symbol to trigger this bug. > > I'll be attempting to do that today. And I failed. I've not found the "magic" combination of buttons to make any difference in block_lookup_symbol. Nonetheless it is not quite so straight-forward in the BLOCK_FUNCTION case where we have to decide what is a "better" match: SYMBOL_DOMAIN == domain && SYMBOL_IS_ARGUMENT or SYMBOL_DOMAIN != domain (but symbol_matches_domain returns 1) && !SYMBOL_IS_ARGUMENT In that case, I cannot say which is more correct. Moreover I have been unable to figure out how to test this. I worry that I would simply be introducing a regression. IMO this is getting into "risky" territory. [But then my philosophy is "if it ain't broke, don't fix it." As far as I can tell, block_lookup_symbol is not "broke."] So what do maintainers want me to do? Keith