From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47462 invoked by alias); 25 Jun 2015 18:26:42 -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 47446 invoked by uid 89); 25 Jun 2015 18:26:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,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; Thu, 25 Jun 2015 18:26:40 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id CBA60AED76; Thu, 25 Jun 2015 18:26:39 +0000 (UTC) Received: from valrhona.uglyboxes.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5PIQcFU006002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2015 14:26:39 -0400 Message-ID: <558C47DE.2070602@redhat.com> Date: Thu, 25 Jun 2015 18:26: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: Doug Evans CC: gdb-patches@sourceware.org Subject: Re: [RFC] Revisit PR 16253 ("Attempt to use a type name...") References: <047d7b2e4e86d2189d05194b7fc3@google.com> In-Reply-To: <047d7b2e4e86d2189d05194b7fc3@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00554.txt.bz2 On 06/24/2015 04:02 PM, Doug Evans wrote: > A variation of PR 18150? > You need to put the symbols in an unexpanded symtab, > the catch being that gdb expands the symtab with main() at startup. > Doh! That does indeed do it! > > 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 > > I'm not sure either. I'm not sure the BLOCK_FUNCTION case > can even exercise this bug. Forest/trees. Darn my vision! :-) > > > 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? > > How about this? That looks good to me, and is fully covered by the test suite. /me very happy Keith