From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30112 invoked by alias); 17 Jun 2015 15:50:09 -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 29566 invoked by uid 89); 17 Jun 2015 15:50:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,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; Wed, 17 Jun 2015 15:50:06 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 3C759B8BCB for ; Wed, 17 Jun 2015 15:50:05 +0000 (UTC) Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5HFo4fL000432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jun 2015 11:50:04 -0400 Message-ID: <5581972B.3020200@redhat.com> Date: Wed, 17 Jun 2015 15:50: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: Jan Kratochvil CC: gdb-patches@sourceware.org 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> In-Reply-To: <20150617123357.GA12138@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00366.txt.bz2 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. Keith